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Távoli elérés megvalósítása VPN reconnect-tel 


A különböző munkakörnyezetek fejlődésével párhuzamosan Milánovics 
kialakult annak követelménye is, hogy a felhasználók immáron Krisztián 
ne csak a belső hálózatról, de minden egyéb tartózkodási 
helyről is elérhessék a céges állományokat és szolgáltatásokat. 
Ezzel a rövid kis cikkel a Windows Server 2008 R2 

. , , .. , , , , , MCSA, MCSE, 
megjelenésével debütált VPN Reconnect szolgáltatásról, és MCTS. MCITP EA 
annak üzembe helyezéséről szeretnék egy áttekintő, technikai MCITP SA 





összefoglalót adni. 


Az alapkoncepció 

Igen, itt rögtön meg is lehetne jegyezni, hogy: , de már idáig is volt három választásunk VPN hálózatok 
kialakítására". És ebben mindenkinek tökéletesen igaza is van. Ott volt — illetve van — a PPTP, LT2P/IPSec 
és a Vista SP1-gyel megjelent SSTP is. Én magam sokszor használtam és használom is ezeket a 
megoldásokat, többnyire segítették is megvalósítani a célt, amiért egyáltalán üzembe helyeztem őket. 
Amiért azonban sokan nem szeretik őket, talán az, hogy egyrészt a felhasználónak magának kell 
gondoskodnia a csatlakozásról, másrészt amennyiben az internetkapcsolat megszakad, az egész VPN 
kapcsolatot manuálisan újra fel kell építeni. Lényegében erre a problémára szeretne megoldást találni a 
VPN reconnect. Alapjába véve ez egy IPsec tunnel módra épülő megoldás, mely az , IKEv2 Mobility and 
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Multihoming Protocol" (MOBIKE) használatának segítségével változtatja meg az , alagút" felhasználó 
felöli végpontját abban az esetben, ha a felhasználó átvált egy másik internetkapcsolatra. 
Természetesen ha egy LAN hálózat kábelét kihúzzuk, majd átváltunk egy WiFi hotspotra, fizikai 
értelemben a kapcsolat egy időre nyilván megszűnik. És itt jön a trükk: a helyett, hogy evvel a VPN 
kapcsolat is véget érne, egyszerűen átvált , DDormant" módba, és mindaddig vár, még újra képes 
kapcsolatot létesíteni az RRAS szerverrel. Ha ez ismét teljesül, a VPN kapcsolat újra felépül, és 


gyakorlatilag ott folytatódik, ahol a váltás előtt abbamaradt. 


ii 





a 
B 


Hotspot WiFi 


IKEv2 Comrp 





ábra 1: Az alapkoncepció 
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Technikai megvalósítás 
Az egész megvalósításához szerencsére nagyon sok mindenre nincs szükségünk. Amint sejthető, kell egy 
RRAS szerepkörrel felvértezett, kizárólag Windows Server 2008 R2-t futtató masina, magához a VPN 


Reconnecthez pedig egy számítógép tanúsítvány. Fontos, hogy evvel a tanúsítvánnyal kapcsolatban két 
dolognak kell teljesülnie: 


e — Igényléskor a , Name" mezőbe azt az FODN nevet írjuk, amellyel kívülről érjük el a szervert. 
Abban az esetben, ha a tanúsítvány egy belső névre szól, a kapcsolat nem fog felépülni. 


e "A másik pedig, hogy a tanúsítvány Enchanced Key Usage (EKU) mezejében két dolog szerepeljen: 
az , IP security IKE intermediate" és a , Server Authentication". Ezt talán a legegyszerűbb úgy 
megvalósítani, hogy a Certificate Templates konzolban duplikáljuk az IPsec templatet és az így 
létrejött másolatot egyrészt elnevezzük VPN Reconnect-nek, valamint az EKU mezőbe felvesszük 
a Server Authenticationt (a másik eleve ott lesz, mert az IPsec tanúsítvány tartalmazza). 


Ha evvel elkészültünk, már csak a , Network Policy and Access Services" szerepkör telepítésére van 
szükség. A telepítés befejeztével a , Routing and Remote Access" konzolban a VPN szerverre jobb klikket 
kattintva a , Configure and Enable Routing and Remote Access" varázsló segítségével már könnyedén 
üzembe helyezhetjük magát a VPN szolgáltatást. 





"General  Detals ] Certification Path ] 





show:  JExtensions Cnly 





GE] Certificate Template Inform... . Template—- VPN Recaonnect SER.. , 


trr] subject Key Identifier 0384 4d 89 69 da b2 9f 7f 60 ,,, 
[irl Authority Key Identifier KeyID-c6 33 49 82 84 df c4 4... 
zel] CRL Distributian Paints [1]ERL CDistribution Paint: Disítr, , , 
gr] Authority Information Access  [ilAuthor]ty Info Access: ACcc. . . 






Enhanced Key Usage server Authentication (1.3.6.... 
[irl Application Policies [/Applicatian Certificate Palic. . . 
[E] Key Lsage Diaital Signature, Key Encipher . , , 





server öuthentication (1.3.6.1.5.5.7.3.1) 
IP security IKE intermediate (1.3.6.1.5.5.8.2.2) 


Edit Properties. . . Copy ta Hile. . . 


Learn more about certificate details 





ábra 2: A tanusítvány EKU-ja 


Currently connected tos 


technet. local 
Mo Internet access 
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VFN Connecti.. . Dormant: Server Unavailable 2 


Disconnect 


Üpen Metwork and sharing Center 





ábra 3: Dormant mód 


Authentikáció 

A VPN megoldások kialakításánál mindig felmerül a hitelesítés és az azt körülvevő problémák kérdése. A 
VPN Reconnect használatakor vagy a számítógépet (tanúsítvány), vagy a felhasználót (jelszó és 
tanúsítvány alapon) hitelesíthetjük. Amennyiben az elsőt, akkor attól függetlenül, hogy éppen melyik 
felhasználó indítja a csatlakozást, semmiféle hitelesítésre nem lesz szükség, egyszerűen a connect-et 
megnyomva a VPN kliens csatlakozik. Ehhez egy , Client" tanúsítványt kell igényelni a kliens gép részére, 
valamint a számítógép tanúsítvánnyal való hitelesítését külön engedélyezni kell a VPN szerveren. A 
felhasználói hitelesítésnél választhatunk jelszó (EAP-MSCHAPv2), illetve tanúsítvány alapút, ahol a 
felhasználó tanúsítványát tárolhatjuk akár a profiljában, akár smart kártyán. 


Összehasonlítva más megoldásokkal 

Ebben a végső pontban két összehasonlítást emelnék ki: az LT2P-t, mivel mindkét megoldás IPsec-re 
épül, illetve a DirectAccess-t, a mobilitási , képessége" miatt. Ahhoz, hogy a VPN Reconnectet az L2TP-vel 
összehasonlíthassuk, fontos tudni, hogy az L2TP használatakor először egy számítógép authentikáció 
történik, amit követ egy felhasználói hitelesítés. Mivel a számítógép hitelesítése kötelező, ez azt jelenti, 
hogy az összes kliens gépre telepíteni kell egy számítógép tanúsítványt, ami jóval megnehezíti az L2TP 
bevezetését. Másrészről tudjuk, hogy a VPN Reconnecthez hasonlóan a DirectAccess is a háttérben 
újracsatlakozik, ha a felhasználó Internet elérést vált (vagy csak szimplán megszakad a kapcsolat), ám 
bevezetéséhez IPv6 infrastruktúra szükséges, és ami számomra talán még fontosabb, hogy a számítógép 
mindenképpen tartománytag kell, hogy legyen (hisz csoportházirenden keresztül kapja a DirectAccess 
beállításokat). Ez megint csak elénk tár egy igen nagy akadályt, mivel koránt sem garantálható, hogy az 
összes olyan számítógép, amelyről a felhasználóknak távoli elérést kell biztosítanunk egyáltalán látott 
már életében Active Directoryt. Összevetve tehát számos távoli elérést biztosító megoldás áll jelen 
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pillanatban egy rendszergazda rendelkezésére, nyilvánvalóan a döntését mindenki a különböző 
körülményeknek megfelelően fogja meghozni, ám az biztos, hogy a VPN Reconnect személyében egy 
gyorsan bevezethető, kényelmesen használható, ámde biztonságos megoldást kapunk. 
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Protocol Name Description 


MetmanFilter 


MetworkinfoEx 


EsP 
E5P 
E5SPF 


E5PF 


ábra 4: IPsec ESP csomagok áramlása a hálózati adapteren 


NetmonHiter:Updated Capture Filtei 
MNetworkinfoEx:Metwork info for , Mi 
ESP:SPI — üxsbdőfc2z2, 5eg - 0X37 
ESP:8PI — üxbűsGfdid, 5eg - üxic 
ESP:5PI — üxsbdőfc22, 5eg — 0X37 
ESP:5PI — üxbűGefdid, 5eg — üxic 


Colurmirrs " 


satb 


ESP:8PI — üx5bdöfc22, Seg - 0x37]F 


ESP:SPI — OxbüGefdid, 5eg — üxic 
ESP:8PI — üx5sbdöfc2z, seg - 0x37 
ESP:5PI — üxbűGGfdid, 5eg — üxic 
ESP:5PI — Oxsbdöfc22, 5eg — 0X37 
ESP:SPI — OxbűGéfdid, 5eg — Üxic 


IPva:Mext Frotocol — üx34, Payloaci 


ESP:SPI — OxbOGefdid, Seg — üxic 
ESP:5PI — Oxsbd3fc22, 5eg - 0X37 
ESP:5PI - üxbűGGfdid, 5eg — üxic 
ESP:5PI — üxsbdőfc22, 5eg - 0x37 
FESP-SET — fyhnésfdid Sen — Mir 
b 
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Hyper-V - Dinamikus memória alapok 

A Windows Server 2008 R2 Service Pack 1 telepítése után, a Liszák Gábor 
Hyper-V szerepkörének képességei között megjelenik a 
dinamikus memória konfiguráció. A dinamikus memória 


lehetőséget ad arra, hogy a virtuális gépeink számára szükség 
Magyar Posta Zrt. , 


esetén több memóriát biztosítsunk automatikusan, a szerver KN 
Rendszermérnök 


leállítása nélkül. Az új képesség használatával több virtuális 
gépet futtathatunk a hoszt kiszolgálón, gazdaságosabb 





memóriahasználatot érhetünk el, és felkészülhetünk a gépeink 
változó erőforrásigényeinek hatékony kiszolgálására. 


A korábbi (SP1 előtti) verzióban a VM-ek számára allokált memóriamennyiség egy fix érték volt, amelyet 
a virtuális kiszolgáló teljes egészében lefoglalt a fizikai memóriából. A memória mennyiségét kizárólag a 
gép leállítása után módosíthattuk. A fizikai memória egy kulcsfontosságú paraméter, amely 
meghatározza a hoszton futtatható virtuális gépek darabszámát. A gyakorlatban, legtöbb esetben ez a 
szűk keresztmetszet. Nem egyszerű feladat méreteznünk egy adott gép memóriaszükségletét. Produktív 
környezetben kénytelenek vagyunk az előforduló legrosszabb (legtöbb memóriát igénylő) esetre 
felkészülni, akkor is, ha ez az erőforrásigény csak bizonyos időpontokban, időszakokban jelentkezik. A 
dinamikus memória használatával lehetőségünk nyílik egy optimálisabb memóriahasználat elérésére, a 
legjobb teljesítmény megtartása mellett. 


A dinamikus memória működési elve 

A Hyper-V hoszt és a megfelelő, virtualizációt ismerő (enlightened) operációs rendszert futtató virtuális 
gép folyamatosan kommunikál egymással, annak érdekében, hogy meghatározzák a VM aktuális 
memóriaszükségletét. Amennyiben a virtuális gépünk erőforrásigénye növekszik, a hoszt automatikusan 
több memóriát biztosít számára. Amennyiben az erőforrásigény csökken, vagy egy magasabb prioritással 
konfigurált virtuális gépnek több memóriára van szüksége (és a rendelkezésre álló fizikai memória 
elfogyott), a hoszt csökkenti a gép számára biztosított memória mennyiségét. 


A szervizcsomag telepítése után a virtuális gépek beállításlapján, a memóriakezelés alatt az alábbi ablak 
jelenik meg: 


Ea Settings for TESZTYMOZ 


Snapshot File Location 
C:AProgramDatalMicrosoftiwindo, , , 
Automatic Start Action 
Restart if previously running 

19) Automatic Stop Action 
Save 





ábra 5: Settings 


Választható memóriakezelés 
A Memory management rész alatt az alábbi konfigurációs lehetőségek jelennek meg: 


HA Settings for TESZTVMO3 





ábra 6: Memory management 


Static: Statikus memóriahasználat. Ezen lehetőség kiválasztásával nem engedélyezzük az adott virtuális 
gépen a dinamikus memóriahasználatot. A Hyper-V, az itt megadott memóriamennyiséget osztja ki a VM 


számára induláskor. Az érték menet közben nem változik, kizárólag a gép leállítása esetén módosítható. 
A beállítás megegyezik az SP1 előtti memóriakezeléssel. 


Dynamic: Engedélyezzük a dinamikus memóriahasználatot. Amennyiben ezt a beállítást választjuk, meg 
kell adnunk a kezdeti memóriamennyiséget (Startup RAM) és a maximális memóriamennyiséget 
(Maximum RAM). 


Startup RAM: A virtuális gép indulásakor ez a memóriamennyiség kerül kiosztásra és a memória 
soha nem mehet ezen érték alá. (alapértelmezett érték 512 MB). 


Maximum RAM: Ez a virtuális gép számára kiosztható maximális memóriamennyiség 
(alapértelmezett érték 65536 MB). 


Amennyiben a beállítást olyan virtuális gépen engedélyezzük, amelyiken a dinamikus 
memóriahasználatot nem támogató operációs rendszer fut, a Hyper-V a Startup RAM alatt megadott 
memóriamennyiséget allokálja a VM számára induláskor, mint statikus memóriamennyiség. A 
beállításokat a gép leállítása után módosíthatjuk. 


Buffer 

Dinamikus memóriakezelés használata esetén a Hyper-V, a VM-be telepített teljesítményszámlálókon 
keresztül folyamatosan figyeli az aktuálisan használt memóriamennyiséget, és ennek függvényében 
határozza meg a virtuális gépünk memóriaszükségleteit. A Hyper-V által számított memóriaszükséglet a 
gépünk által használt aktuális memóriamennyiségből és további tartalék memóriából (buffer) tevődik 
össze. A tartalék memória mennyiségét virtuális gépenként konfiguráljuk, és százalékos értékben adjuk 
meg. 
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Íreszrvmoz r] a G 
A Hardware s Memory —— SET 
4 Add Hardwáró 
(KI 8t0s You csn configure options for assigráng and mansging memory for this virtual machine, 
Hi Memory management 
iga Specfy a set amount of memory for thés virtual machine, or let Hyper-V manage the 
1 amount dynamicaly within the specfied range. 
(d Processor 
j C Static 
3 MÜ 10E controller 0 Hága fsz me 
e. Hard Orfrve 
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- HÚ IDE Controler 1 Startup RAM: 512 MB 
íá OVO Oríve 
? Maximum RAM: ésszó MB 


A! SCSI Controller 
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et t buffer. Hyper-V uses the percentage and the axrent demand for memory tö 
determine an amount of memory for the buffer. 
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GY COM1 
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Memory weight 


Specify how to prioritize the avalabáty of memory for thés virtual machine 


bed Dickette Drive 
hy compared to other virtual machines on this computer , 
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7 Integration Services í) specifying alower setting for this virtual machine might prevent it from 
3 starting when other virtual machines are running and avaldable memory is low. 
a. Snapshot Fée Location 


5 Automatic Start Action 


[00 Automatic Stop Action 
ho ] cm [/ ag ) 


ábra 7: Memory buffer 


A virtuális gép számára kiajánlott összes memória értékét, a bufferbeállítás függvényében az alábbi 
képlet határozza meg: 


Virtuális gép memóriája - aktuálisan használt memóriamennyiség 1 buffer [96] 


Például: ha a VM aktuális memóriaszükséglete 2000MB és a buffer értékét 209- ra állítjuk akkor a 
virtuális gép számára 2400MB memóriát fog allokálni a hoszt. Természetesen a Maximum RAM alatt 
definiált értéket nem haladhatja meg. A buffer értékét az adott virtuális gépünk és az azon futó 
szolgáltatás memóriahasználatának szokásaihoz kell igazítanunk. 


Súlyozás 

Ez a képesség kizárólag akkor jön a képbe, ha a hoszt összes rendelkezésre álló fizikai memóriája 
elfogyott. Amennyiben van szabad fizikai memória, úgy a virtuális gépeken megjelenő memóriaigény 
abból kerül kielégítésre. Amikor nincs elég fizikai memória a virtuális gépeket futtató kiszolgálón, és 
egyszerre több VM-nél jelentkezik a többletmemória igény, a Hyper-V-nek el kell tudni döntenie melyik 
gép(ek) igényeit szolgálja ki. Ebben segíti a memória prioritás. A csúszka az alacsony (Low) és a magas 
(High) közötti tartományban mozgatható relatív érték. 
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determine an amount of memory for the buffer. 
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N Memory buffer: 20 9 
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id Déskette Orívé A ; 
Spoecdfy how to prioritíze the avadabáty of memory for this virtual machine 
compered to other virtual machines on this computer , 
A nt 
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7- Integration Services 


új) specifying a lower setting for this virtual machine méght prevent it from 
starting when other virtual machines are running and avadabba memory is low. 





a! Snapshot Fde Location 
5 Auktomatk Start Action 


Í9) Automatk Stop Action 
EEjEsETesz 


ábra 8: Memory weight 


A memória prioritás a következőket befolyásolja: 


- . A Hyper-V először a magasabb súlyozással rendelkező gépeket szolgálja ki, számukra biztosítja 
többletmemóriát. 

- . Magas súlyozással konfigurált gépek többletmemória szükséglete esetén, a legalacsonyabb 
súlyozással rendelkező géptől fog először memóriát elvenni (természetesen, ahogy ezt már 
korábban is hangsúlyoztuk, erre csak akkor lesz szükség, ha a hoszt összes fizikai memóriája 
kiosztásra került). 


A szervizcsomag telepítése 

Upgrade esetén, a hoszton futó gépek beállításai alatt, a korábban (SP1 előtt) konfigurált 
memóriamennyiség a Static RAM mezőben jelenik meg. Tehát frissítés után a dinamikus 
memóriahasználat automatikusan nem lesz engedélyezve. 


A Windows Server 2008 R2 SP1 telepítése után a virtuális kiszolgálóinkon telepítsük újra az Integration 
Services-t. 

A VM Virtual Machine Connection ablakában kattintsunk az Insert Integration Services Setup Disk 
lehetőségre az Action menüpont alatt, majd a szerverre belépve kövessük végig a telepítés folyamatát 
(amennyiben Windows 7 vagy Windows Server 2008 R2-t futtatunk a virtuális gépünkön, az is megfelelő, 
ha itt is telepítjük az SP1-et). 
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File üction Media €Clipnboard Yew Help 
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Save Ttrl--ü 


FPause (trl--P 
Reset, , , Ctrl--R 


srnapshat, , , —Erl--H 
Revert. , . Ctrl--E 


Insert Integration Services Setup Disk. 


Press CTRL -- ALT -- DELETE to log on 


ábra 9: Insert Integration Services Setup Disk 


A szervizcsomagnak egyelőre a Release Candidate (RC) változata érhető el. 


Letöltés: http://technet.microsoft.com/hu-hu/evalcenter/ff183870(en-us).aspx 


Természetesen a jövőben foglalkozunk még a dinamikus memóriával, alkalmazásának feltételeivel, 
javasolt használatával stb. a www.technetklub.hu oldalon. 
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Alternatív kliens stratégia 


Sokan úgy gondolják, hogy csak azok a nagy, fontos és drága Somogyi 
rendszerek alkotják az informatikát, amelyeket a Csaba 
számítóközpontok bombabiztos falai mögé rejtünk. Pedig azok 

BCSS kft 


a rendszerek sem kevésbé fontosak, amiket a felhasználóink 


kezébe adunk napi használatra: az ő számukra ugyanis MCP, MCSE, MCT, 


MCITP, MCTS, ITIL 
Foundation 


nagyrészt az az informatika és a kapott megoldás minősége 
döntően meghatározza a véleményüket — a mi munkánkról. A 





következő cikkben arra keresek választ, - főleg IT vezetői —77555SSSSSESSS 
szemszögből - milyen szempontok alapján érdemes a kliens környezetet megtervezni, miért célszerű a 
hagyományos, nagy, statikus és zárt rendszer helyett, kisebb egységekből felépülő, kompozit egységeket 
létrehozni. 


Az kliens stratégia választás során felmerülő első kérdés mindjárt az, hogy milyen részekből áll(hat) ez a 
kliens stratégia és ezek hogyan függenek össze az egyes területek egymással. Íme, egy koránt sem teljes 
lista és a leggyakoribb kérdések: 


Hardver választás 


e — Egy vagy több gyártó? (Az egyszerűbb garanciális ügyintézés ér többet vagy az olcsóbb ár?) 

e . Mennyire legyen egységes a géppark? 3-5 év alatt ez mennyibe kerül, fenntartható-e egyáltalán? 

e . Valóban mindenkinek egyforma gép kell? Mi kerül többe, túl erős gépeket adni vagy többfélét 
felügyelni? 

e  — Mi legyen a VIP igényekkel? (A "trendi" eszközök kezelése: Mac-ek, tabletek és egyéb kütyük) 


Operációs rendszer választás 


e — A drága az olcsóbb, vagy az olcsó a drágább? Olcsó-e az ingyen operációs rendszer, ha senki sem 
ért hozzá a cégnél? Számít-e, mérik-e a kliens támogatásra fordított időt? 

e —. Hány operációs rendszer generációt támogassunk egyszerre? Milyen gyors lehet egy átállás 
(megvárjuk-e az SP1-et)? 


Lemezkép startégia 


e . Mennyi lemezkép optimális egy cégnél? Létezik-e univerzális image? 
e — Vékony, félkövér vagy vastag lemezkép? (Melyik, mit is jelent?) 


Alkalmazások 


e — Tudjuk-e egyáltalán, milyen alkalmazásokat használnak munkatársaink? Mennyiért fizetünk, 
amit nem használ senki? Miből van sok vagy éppen kevés? 

e — Alkalmazáskatalógus és portfólió (A "jövő-levő-menő" alkalmazások dilemmája és ezek 
finanszírozása) 


e — Van-e értelme (legalább egy riport erejéig) kimutatni, ki mit használ? 


Az 


Felhasználói adatok 


e — Hol a helyük? Helyi vagy központi tárolás? 
e — Bizalmasság és adatvédelem - együtt vagy egymás ellen? 
e Kia tulajdonos -az egyén vagy a vállalat? 


A lista koránt sem teljes, inkább csak szemléltetésnek szántam, hogy lássuk: valóban összetett kérdésről 
van szó. Mielőtt azonban részletesebben körüljárnánk a felvetett területeket, következzék egy kis 
közgazdasági kitérő. 


A kliens stratégia választás vitathatatlanul komoly következményekkel járó döntés, mindenképpen 
célszerű számokkal alátámasztani pl. a lehetséges megtakarítások, az élőmunka ráfordítás vagy a 
munkaidő kiesés vonatkozásában. Persze egyáltalán nem mindegy, mit mérünk és hogyan. A klasszikus 
vicc jutott erről eszembe: 


"Gépház! Mennyi? Háromszázhúsz. Mi háromszázhúsz? Mi mennyi?" 


Elméletileg lehet egy olyan mutató, ami segíthet az egyes megoldások összehasonlításában, úgy hívják 
TCO (Total Cost of Ownership). Gyakorlati alkalmazása, kiszámítása azonban egyáltalán nem gyerekjáték, 
lássuk mik a fontosabb fenntartások a TCO-val kapcsolatban. 


A leggyakorlatiasabb kifogás az, hogy annyiféle paraméterét kelllene) ismernünk az informatikai 
ökoszisztémánknak (ugye, milyen szép, tudományos kifejezés?), ami az esetek döntő többségében nem 
áll rendelkezésre. A hardver és szoftver költségeket a számlák alapján még csak-csak össze tudjuk 
gyűjteni. De van-e adatunk arra, hogy mennyi élőmunkát kell egy-egy számítógépre fordítani évente? 
Ennek az élőmunkának milyen a szakmai mélysége és ebből következően a költsége? Tíz-húsz incidens, 
amit egy kezdő technikus is el tud hárítani valószínűleg lényegesen kevesebbe, kerül, mintha egy 
rendszermérnök dolgozik egy-két órát (történetesen a főnök) notebook-ján. Tudjuk-e számszerűsíteni 
azt a veszteséget, amit a munkakiesés okoz egy-egy számítógép üzemképtelensége alkalmával? Egy 
elvesztett hordozható gép tényleg csak annyit ér, amennyi a főkönyvi értéke? Tudjuk-e mérni az 
elvesztett adatok értékét (reprodukálás költsége, esetleges üzleti hátrányok, presztízsvesztés stb.)? 


Aztán ha a jelenlegi költségekkel meg is vagyunk, hogyan derítsük fel az alternatívaként felmerülő 
megoldások költségeit (ezeket jelenleg nem üzemeltetjük, tehát hiányosak a bemenő adataink), és 
hogyan biztosítsuk, hogy ezek összevethetők legyenek egymással? Meg tudjuk-e előre mondani, 
mennyibe fog kerülni egy másfajta technológiai megoldás? Hogyan kezeljük a bevezetés 
többletköltségeit (mert ilyenek biztosan lesznek)? 


Ha pedig megszületik valamiféle összehasonlítás, még mindig szembesülhetünk azzal a ténnyel, hogy a 
TCO, mint egyedüli mutató torzíthat is. Ha kicsit közgazdászosabbra vesszük (bár, megjegyzem, nem 
vagyok az): ha a kapitalizmusban minden gazdasági vállalkozás profitjának maximalizálására törekszik, 
akkor csak a fele utat teszi meg a sikerhez az előállítási költségek minimalizálásával. Az út másik fele, a 
bevétel maximalizálása pl. monopolhelyzet, versenyelőny, piaci trend kihasználásával. 


Röviden lefordítva a mi kérdéskörünkre: a leghatékonyabb kliens stratégia az, amelyik a teljes költség 
(TCO) és az üzleti eredmény között a legnagyobb különbséget képes kialakítani. Hiába alacsony a TCO, ha 
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az adott technológiai megoldás nem segíti az üzletet az eredményességben, viszont egy drágább 
technológia bevezetésének is lehet értelme, ha extra magas profit megszerzését segíti elő. 


A közgazdaságtanról mára ennyit. 


Mi lehet akkor az értékelés módja? Mit tegyünk, ha nem tudunk, nem akarunk valódi TCO-t számolni? Az 
egyszerűsített modell lehet például rangsorolás: állítsuk sorba az egyes technológiai területeken 
felmerülő megoldásokat, majd a helyezéseket összesítsük. A legkisebb helyezési számú megoldáscsoport 
lehet a nyertes. A modellt bonyolíthatjuk azzal, hogy jelöljük azokat a technológiákat, amik műszaki 
okokból vagy költségességük miatt nem alkalmazhatók együtt. Az eredmény akár grafikusan is 
ábrázolható, ha jól választottunk szempontokat, akkor a legkisebb területet lefedő technológiai 
megoldás lehet a számunkra optimális. Az illusztrációként készített ábrához nem is teljesen önkényesen 
választottam értékelési szempontokat: a rugalmasság, az időráfordítás, a reprodukálhatóság és a 
helyreállíthatóság négy jelentős tényező, amikor választanunk kell, de ezekről essék szó a technológiai 
részleteknél. 


Rusgalmasság 


Aa jú 


u Megoldás 1 


u Megoldás 3 


Helyreállíthatóság ő 4 sú s Időráfordítás lélőmunkal 
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Minőség (reprodukálhatóság] 





ábra 10: A négy fontos tényező 


A kliens stratégia természetesen nem lineáris, folyamatosan előrehaladó tervezési folyamat 
eredményeként születik. A cikk elején található lista elemeit többször, újra át kell gondolni, hogy 
valamennyi függőséget és azok kihatásait átlássuk. Az átláthatóság megteremtésében lehet 
segítségünkre a Microsoft Desktop Optimization (MDOP) megoldása, ami - a remek technológiai 
megoldások mellett - módszertani segítséget is nyújt a sikeres stratégia kidolgozásához. 


6 a 


Feladat orientált Mobil Szerződéses Iirodista . Távmunkás 





A rendrakást kezdjük azzal, hogy számba vesszük, mire is fogják használni a felhasználók a nekik 
biztosított informatikai eszközöket (szigorúan maradjunk az üzletileg indokolt tevékenységeknél)! 
Igyekezzünk a felhasználói igényeket néhány tipikus kategóriába sorolni! A kategóriák felállításánál 
használhatjuk az MDOP dokumentáció öt kategóriáját (feladat munkás, irodista, szerződéses munkaerő, 
mobil felhasználó, távmunkás) vagy létrehozhatjuk a saját típusainkat. A felhasználói típusokhoz 
keressük meg a számukra optimálisnak tekinthető kliens megoldást. Az átláthatóság kedvéért ebből akár 
táblázatot is készíthetünk, amiben a cikk elején felsorolt szempontokat is feltüntethetjük. 


Feladat munkás Mobil Szerződéses ! Távmunkás 
felhasználó 


típusa vékony kliens notebook PC vékony 
mee jer ls 
saját 
nagy közepes 


Operációs rendszer Windows Windows 7] Windows7 1! Windows Windows 
ajánlott  (RDP I Bitlocker-rel ajánlott ajánlott 
verzió miatt) (RDP verzió I (RDP verzió 

miatt) miatt) 


Lemezkép nincs vékony vékony nincs nincs 


Alkalmazásterítés APP-V APP-V APP-V RDS 4 APP- ! RDS 4 APP- 
(cached) VvagyVDI !VvagyVDI 


Felhasználói adatok Átirányított Átirányított ! Átirányított ! Átirányított ! Átirányított 
mappa 1 RDS ! mappa mappa mappa mappa 
profil (offline (offline 

mód) mód) 





Természetes, ha a táblázat egyes celláit nem tudjuk azonnal és habozás nélkül kitölteni, minden egyes 
döntésünk mögött rengeteg megfontolandó szempont állhat. Sőt, akár több ilyen táblázatunk is lehet, 
amiben a részterületek optimális kombinációit keresgéljük. Mintaként vezessük most végig a fenti 
táblázatban látható példát! 


A feladat munkásoknak vékony klienst szánunk, hiszen ők kevés féle, de gyakran ismétlődő feladatot 
végeznek, folyamatosan a hálózathoz csatlakozva. A feladataik nem igényelnek különösebb számítási 
kapacitást és a grafikus megjelenítés minősége sem szempont. A vékony kliensektől nagyobb 
megbízhatóságot (nincs mozgó alkatrész) és kisebb karbantartási igényt várunk el (noha ez a tévhitekkel 
ellentétben nem nulla!). A másik oldalon a vékony kliensekkel természetesen szembe kell állítani 


SÍ6 


valamilyen központi szolgáltatást, amit használhatnak, ez most legyen Remote Desktop Services, mert 
nagyságrendekkel olcsóbb, mint egy virtualizált deszktop. Az alkalmazásokat az RDS kiszolgálókra APP-V 
csomagok formájában juttathatjuk el (Windows Server 2008 kompatibilitás ellenőrizendő!), mert ebben 
a formában jelentősen jobb lehet az RDS szerverünk kihasználtsága — az alkalmazások frissítése nem 
igényli a kiszolgáló újraindítását. A felhasználóknak szinte nincsenek is a munkájukhoz kapcsolódó 
tárolandó adataik, ehhez mérten adhatunk nekik tárkapacitást a fájlszerverünkön. 


A táblázat egy ágát végigjárva, már látszik az a sajátosság, hogy pl. a kliens formátum (esetünkben a 
vékony kliens) megválasztása hogyan szűkítheti be a további választási lehetőségeket az operációs 
rendszer vagy az alkalmazásterítés vonatkozásában. 


A második csoport a mobil felhasználók csoportja, és a csoport neve már tartalmazza specifikus 
igényüket: munkájuk végzése során gyakran nem kapcsolódnak közvetlenül a helyi hálózathoz és 
lehetnek olyan feladataik, amelyek számítási és/vagy grafikus teljesítményt igényelnek az általuk 
használt eszközben. Szolgáljuk ki az ő igényeiket a lehető legkevesebb új komponens bevonásával! 
Megtarthatjuk az alkalmazás virtualizációt, mint  alkalmazásterítési technológiát, hiszen van 
lehetőségünk az alkalmazások cache-be töltésére, amikor a felhasználó a hálózathoz csatlakozik (akár 
Internet-en keresztül is) vagy MSI csomag formájában adathordozóra is tehetjük virtualizált 
alkalmazásainkat. Operációs rendszernek válasszuk a Windows 7-et, egyrészt az offline mappák 
hatékonyabb kezelése, másrészt a Bitlocker miatt. A lemezképet se bonyolítsuk túl: akár Windows 
Deployment Services-t (WDS), akár Microsoft Deployment Toolkit-et (MDT) vagy éppen System Center 
Configuration Manager-t (SCCM) használunk az operációs rendszer terítésére, van lehetőségünk arra, 
hogy a szükséges eszközvezérlő készletet dinamikusan csatoljuk az operációs rendszer gyári telepítő 
készletéhez. Alkalmazásból pedig mindössze kettő kell: az APP-V kliens és a vírusirtó. Ezeket MDT-vel 
vagy SCCM-mel telepíthetjük, viselkedésüket pedig házirendekkel központilag szabályozhatjuk. A 
felhasználói adatokat a mappa átirányítási csoportházirendekkel tereljük át fájlszerverre, ezzel 
egyszerűsödik mentésük és nem veszítjük el őket, ha notebooknak nyoma vész. (Zárójelben jegyezzük 
meg, hogy az operációs rendszer választás kihatással van a hardver választásra: még beleszaladhatunk 
raktárkészletről, nagy kedvezménnyel árult, ámde Windows 7-re nem minősített hardverrel!) 


Irodai munkásaink kapjanak mostani példánkban hagyományos PC-t (ezt megszokták, szeretik és tegyük 
fel szükségük is van rá)! Tartsuk meg hozzá a meglévő vékonyka Windows 7 lemezképünket, persze 
egészítsük ki a szükséges eszközvezérlőkkel! Telepítsük az operációs rendszert, ahogy a notebook-okét, 
telepítsük az alkalmazásokat, ahogy a notebook-okra! Kezeljük a felhasználói adatokat, ahogy eddig 
mindenkiét (legfeljebb adjunk nagyobb kvótát a fájlszerveren, mint szegény feladat munkásoknak). Ezzel 
a csoporttal bizony nem sok dolgunk akadt, kiszolgálásukhoz minden rendelkezésre állt már. 


Az utolsó két felhasználói típus nálunk egyelőre még nem túl gyakori, akár össze is vonhatjuk őket, mert 
sokban hasonlítanak egymásra. Példánkban sem a szerződéses munkatársnak, sem a tásrmunkásnak nem 
biztosítunk hardver eszközt. A szerződő (megbízott) az őt bérbe adó cég gépét használja, a távrmunkás a 
sajátját. Ebből következően hálózati hozzáférésüket a minimálisra szeretnénk csökkenteni, nem is 
engedünk nekik mást csak RDP használatát (és lehetőleg azt is Network Access Protection mellett). Az 
esetek többségében biztosan elegendő lesz munkájukhoz, ha egy RDS kiszolgálón biztosítjuk számukra a 
szükséges alkalmazásokat (mi mással, ha nem ismét APP-V-vel, hiszen adott az infrastruktúra, sőt akár az 
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alkalmazáscsomagok is). Ritkább esetekben, például ha szerződéses vagy tásrmunkás munkatársunk egy 
új alkalmazást fejleszt és ehhez rendszergazdai jogokra van szüksége, ráadásul gyakran kell újraindítania 
a gépét, biztosítsunk számára egy virtualizált deszktopot. Ehhez ismét használhatjuk a korábban 
létrehozott vékonyka Windows 7-es lemezképünket, ha Hyper-V virtualizációt használunk, már az 
eszközvezérlőkre sincs gondunk. Az alapvető alkalmazásokat ide is küldhetjük APP-V-vel, az egyedi 
dolgok telepítését bízhatjuk a felhasználóra (ha nem boldogul vele, akkor nem indokolt számára a VDI 
kliens 0). 


Ha visszatekintünk a táblázatra láthatjuk, hogy többféle felhasználói igényt egészen kis számú 
technológia rugalmas kombinálásával és újrahasznosításával is ki tudunk elégíteni és igazából még csak 
egyet jártunk végig a lehetséges kombinációk közül. Az ilyen kis részrendszerek kialakítása és fenntartása 
-— bármilyen technológiai szempontból korrekt kombinációban - lényegesen olcsóbb lehet, mint a 
statikus nagy rendszerek hosszas elkészítése és nehézkes karbantartása, miközben megnyerjük a 
rugalmas alkalmazkodás képességét a változó üzleti igényekhez. 
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Adatmentés és visszaállítás a System Center Data Protection Manager 
2010 segítségével 


A mentendő adatok köre folyamatosan változik. A virtualizáció 
terjedésével együtt egyre újabb kihívásokkal találják szembe 


Szirtes István 


magukat a mentéssel foglalkozó szakemberek. Jellemzően az Szirtes 
archiválandó adatok mérete inkább növekszik, mint hogy egy Technologies 
Kft., 


kicsit is csökkenne. Az egyre újabb technológiák bevezetésével 
együtt ez a helyzet csak tovább romlik, hiszen legtöbbször a 
bevezetés legfőbb mozgatórugója a nagyobb terhelhetőség, és ÖNEtTÜGES 

a magasabb fokú rendelkezésre állás. A mentési ablak Manager MVP 
csökkenésével együtt egy újabb kezelendő probléma is 7 Tett 
előtérbe került: ha megtörtént a baj, akkor azt a lehető legrövidebb időn belül el kell hárítani. Ilyenkor 
jöhet jól a megfelelő eszközökkel és jogokkal megtámogatott végfelhasználó általi adat visszaállítás. 
Persze ezek a szempontok csak a , jéghegy csúcsát" jelentik egy mentő szoftverrel kapcsolatos elvárások 
listájában, cikkemben éppen ezért csak szemezgetek a System Center Data Protection Manager 2010 
legfontosabb újdonságaiból. 


System Center 





Az adatmentés területén dolgozó Microsoft szakemberek 2010 áprilisában bizonyára örültek a hírnek, 
hogy megjelent az SCDPM következő verziója, amely immár a harmadik generációs mentési megoldás a 
Microsoft palettáján. 

Az első változatot még Data Protection Manager 2006 néven ismerhettük meg, melynek a legfontosabb 
célja a fiókirodákban előálló adatok központosított mentésének megoldása, ezáltal az egyes telephelyek 
szintéjén a szalagos egységek kiváltása. 

A következő változat már a System Center termékcsalád részeként debütált, de kezdetben ez inkább 
csak a névben jelentett összefonódást a termékcsalád többi elemeivel. Az SCDPM 2007-ben sok új 
fejlesztés látott napvilágot, többek között az Exchange, SharePoint, vagy az SOL alkalmazás kiszolgálók 
mentési képessége. Az SCDPM 2007 SP1 legfontosabb újítása a Hyper-V környezetek és a felhő alapú 
adatvédelmi rendszerek (külső gyártók megoldásaival ötvözve, pl. Iron Mountain) támogatása. 

A DPM fejlesztési koncepciójának középpontjában a kezdetektől fogva az a megközelítés állt, hogy 
egyetlen ügynökön keresztül a Microsoft által készített alkalmazások, kiszolgálói szerepkörök, és a 
felhasználói adatok menthetőek, és szükség esetén visszaállíthatóak legyenek. 

A jelenlegi változat egyaránt támogatja a kiszolgáló és munkaállomás operációs rendszerek mentését, 
amely adatokat akár lemezen, akár szalagon is tárolhatunk. 

Az SCDPM 2010 megőrizte a 2007-es változat konzol felépítését és működési hátterét, így ennek 
elsajátítása sem fog gondot okozni. 

A konzol mögötti fejlesztői ideológia teljesen egyértelmű: minél nagyobb a baj, annál stresszesebb 
folyamat a visszaállítás. Éppen ezért a konzol legyen letisztult és rendkívül könnyen értelmezhető. 
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KH! DPM 2010 Administrator Console 














Create protection group. . . 


4] al09 Protection Group: File Servers (Total members: 1) Modify protection group... 





Stop protection of group. . . 





al9 Protection Group: HyperV Clusters (Total members: 2) 





al9 Protection Group: Protected Client Computers (Total members: 3) 





Manage online protection. . . 





al9 Protection Group: SharePoint Systems (Total members: 1) 





s. Configure self service recover. . . 
aj0g Protection Group: SOL Databases (Total members: 23) 








E al09 Protection Group: System Protection (Total members: 4) 











si Spedfy tape catalog retention. . . 
a09 Protection Group: Virtual Machines (Total members: 3) tdlllságetells 
Modify disk allocation. . . 


Perform consistency check ... 


There are no alerts which are associated with this protection group 
Short-term using disk 

3 days ] Synchronization just before creating a recovery point. 
34,32 GB I Grow automatically Help 


On-wire compression: Disabled [ Consistency check: Automatic when replica becomes inconsistent. / 
Express Full Backup-20:00 Everyday 


Recovery point status. . . 





ábra 11: SCDPM felügyeleti konzolja 


Miután felvettük a rövid távú adatmegőrzési tárterületre szánt merevlemezeket, illetve a hosszú távú 
archiválást biztosító szalagokat, telepíthetjük a mentési ügynököket, beállíthatjuk az értesítési 
mechanizmust, rögzíthetjük a megvásárolt felügyeleti licenceinket, és kezdődhet a mentési csoportok 
létrehozása. A mentésre kijelölhető adattípusok közül lássuk a DPM 2010 legfontosabb újdonságait 
jelentő funkciókat: 


Postafiók elemszintű visszaállítása 


Jó dolog, ha egy komplett Exchange adatbázist tudunk mentésre kijelölni, és persze az sem 
elhanyagolható, ha a mentő szoftver megoldja a feleslegessé vált tranzakciós napló állományok 
kitakarítását. De egy , véletlenül" letörölt postafiók, vagy még inkább egy levél esetén nem fogjuk a 
komplett adatbázist visszaállítani a korábbi állapotára, hiszen így az eredi problémánál is nagyobb bajt 
csinálnánk. A DPM fejlesztői a visszaállítás feladatát részben az Exchange képességeire és annak 
rendszergazdájára bízzák. Egy elemszintű visszaállítás első lépésében a DPM konzoljából kiválasztott 
postafiók egy megadott időpontra történő visszaállítását konfigurálhatjuk, de a következő lépésben 
belebotlunk a Recovery Database igényébe. Ilyet az Exchange 2010-ben nekünk kell PowersShellből 
létrehoznunk. Ha ez megvan, akkor a visszaállítás első lépésén túl vagyunk, hiszen a postafiók adatbázis 
és a szükséges tranzakciós és egyéb rendszer állományok a megadott Recovery DB útvonala alatt 
megtalálhatóak. A folyamat további részei már az Exchange rendszergazda feladatát képezik, ezért csak 
vázlatosan: adatbázis felcsatolása, majd PS-ből a megadott postafiók és a keresési feltételeknek 
megfelelő elemf(ek) visszaállítása. 


SOL adatbázisok automatikus mentése és delegálható visszaállítása 

Az SCDPM 2010 újdonságai között két nagyon hasznos SOL támogató funkció található. Az új verzióban 
akár az egész SOL kiszolgálót is felvehetjük a mentendő erőforrások körébe, ezáltal a rajta kezelt összes 
adatbázis automatikusan mentésre kerül. A hangsúly nem a védelmi csoport megalkotásakor kezelt 
adatbázisokon van, hanem azokon, amiket ezt követően hozunk létre. Gondoljunk például egy 
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SharePoint rendszer tartalmi adatbázisaira. A rendszer dinamikus változásait képes a mentő szoftverünk 
automatikusan lekövetni. 

Az ügyfél igényekre reagálva a fejlesztők beépítették a SOL rendszergazdák számára delegálható 
adatbázis visszaállítás képességét, melyhez egy egyszerű és kézenfekvő visszaállító konzol (DPM Self 
Service Recovery Tool) is társul. Ez utóbbi külön telepítendő a rendszergazdai munkaállomásra az 
SCDPM telepítő készletén található DpmSalEURlnstallerNDPMSOLEur x64.msi (vagy ...x86.msi) 
futtatásával. 


fős Recovery Wizard xi 
ki Specify Alternate Recovery L ocation 
(0 Specify the alternate database, instance and server for recovery. 


Steps 

For the database you are recovering, specify the instance of SOL Server and the name of the 
2 "Welcome recovered database. 
9 Specily database details SOL Server Instance Name: [HOSTO1 r] 
4 Specily recovery point 

Database file location: [Custom path... bat ] 
4 Select recovery type 


Specify alternate recovery Recovered Database Name: [FE PDE 501 


location 


t 





— Database file locations 


9pecily database state If the recovery destination version is 5(1L 2000 then the database file locations have to be the same 
as on the original SL server, for SOL 2005 or later vou can specify database file locations. 


b 


kh 


Specify recovery options 





Database file Database file location 


FEPDB. 501 mdf [c:WProgram FilesiMicrosoft SOL Server MSSOL10. 50.MSSÖLSERVERI 
FEPDB 501 log.LDF [c:AProgram FilesiMicrosoft SOL Server MSSOL10 50.MSSÖLSERVERI 






4 Summary 











(4). DPM will create the folder DEM 18-10-2010 .17.59.23 under the specified location during recovery. 


£ Back [LNer ] Cancel Help 3 





ábra 12: Az SOL rendszergazda által kezdeményezett adatbázis visszaállítása 


SharePoint 2010 elemszintű visszaállítása 

Minél előbb érdemes bevezetni a SharePoint 2010-et, ha másért nem is, akkor az elemszintű visszaállítás 
indokolttá teheti €. 

Miről is van szó? A DPM 2007 és a SharePoint 2007 együttesében az elemszintű visszaállítás csak úgy 
kivitelezhető, ha építetünk egy Recovery Farm-ot, amely tükörképe az éles portál rendszerünknek. Ezt 
követően jöhet az adatbázis visszaállítása, majd a helyreállított környezetből a szükséges tartalmak 
átmásolása az éles rendszerbe. Ez egyaránt erőforrás- és időigényes feladat, amire eléggé nehezen 
szánjuk rá magunkat. Ehhez képest felüdülést jelent a visszaállítás azon módja, ahogy a DPM 2010 ezt 
elénk tárja. Elegendő a portál tartalmi adatbázisát kinyitnunk és kiválasztanunk a szükséges elemet, amit 
a varázsló további lépésein végighaladva akár az éles rendszerbe visszatölthetünk. 
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Jax] 


KÖ! DPM 2010 Administrator Console 
FAle  Acton View Help 

























Fe Monitorii 





— Browse]/. Search] 


Protected data: Recovery points for: MOSSASharePoint. Corfig 




















































































tán TT) EZTET 

Recoverable data október vi 12010 57 on ar. ate 
:£3 SZIRTES.DEMO REESá ENNE SÉ ZENÉT EN Éztntt 

ai down list for the recovery points that you Verify datz 
33. ú HOSTOS Ke 

H- 3 HOSTO5 li open the Recovery Wizard. Configure end-user recovery. . , 
E A HOSTO8 H K Sze Cs P Sz V : 

3. §. HOSTOS ESZNEK EK Ms 
(H- 3. MAILBOXI 4 5 6 7 8 9 10 Recovery date: . október 17 2010 [A Help 

H 3 MAILBOX2 11 12 13 14 15 16I8FÁA 

BH A MOSS 19 20 21 22 23 24 Recovery time: [20-00 r] 

5-átá Al Protected SharePoint Data 25 26 27 28 29 30 31 
at MOSSASharePoint. Config Recoverfrom: — Disk Se 

4- B. RDSH1 

4. 8. RDWEB 

4-8 SCCM 

4]. 8. SCOM 

4-8 W7CLIT 

HE ad W7CLIT (HyperV-Cluster.SZIRTES.DEMO) 

4. 8 W7CLI2 

ál. 8 W7CLI3 

j 

















ád W7CLI3 (HyperV-Ciuster.SZIRTES.DEMO) 

















1 http:(/mossl. catalogsi 

ESÉSE ÉS K ERT KÉSS BEKES] 
Mhttp:!Wmoss/ private/ 
Mhttp:YWmossz evti pvt/ 
mihttp:(Wmossfánalyticskeportsi 
Ehttp:/mossidefault. aspx 
Ehttp:(/mossiFormserverTemplatesi 
Hhttp:Wmossfimagesl 
mhttp:(fmossfIwConvertedFormsil 


ábra 13: SharePoint konfigurációs adatbázisa tallózható formátumban 


CSV alapú rendszerek támogatása 


Amikor mindenhol virtualizációba és a szorosan vele együtt járó magas rendelkezésre állásba botlunk, 
talán nem túl nagy elvárás az sem, hogy a virtuális gépparkot futás közben tudjuk menteni. Alap 
szempont, hogy a mentésben szereplő virtuális gép a futó példánnyal konzisztens állapotban legyen a 
mentés befejezésekor. Ehhez persze megtehetnénk, hogy a mentés idejére mentett állapotba (saved 
state) hozzuk gépeinket, majd a mentés végén elindítjuk azokat, ám ha rövid időre is, de a kiszolgálók 
által nyújtott szolgáltatások így kiesnek. Erre ad megoldást a virtuális gépre telepíthető Plugin VDev 
csoportba tartozó biztonsági mentés (kötetpillanatkép) integrációs komponens, de ehhez a virtuális 
gépnek , felvilágosultnak" kell lennie, tehát szükséges a megfelelő IC komponens és persze a mentő 
szoftvernek is támogatnia kell a funkciót. De mi a helyzet a Cluster Shared Volume alapú osztott 
tárterület kezeléssel, ahol egy időben több virtuális gép adatait helyezhetjük el, melyek szétszórva 
futnak a fürtbe szervezett kiszolgálókon? Ahhoz, hogy az összes hoston futtatott virtuális gépről 
konzisztens állapotú mentés készülhessen, a mentés idejére a DPM ügynök automatikusan átkapcsolja 
az osztott lemez elérését redirect módba. Így az összes VM a LUN tulajdonosán keresztül kerül 
archiválásra. A folyamat végén a LUN elérése visszaáll a normál üzemmódra. 
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[Es Failover Cluster Manager [01 xi 
FRle Action View Help 














653] almilAlm 


ER Failover Cluster Manager 

E E HyperV-Cluster.SZIRTES.DEMO 

a (EG Services and applications Summary of Storage 
i W7CLI1 a 





Recent Cluster Events: Nonein the last 24hours [DSL 





W7CLI3 
BH E Nodes Storage: Total Capacityz 
2 NODE01 3 Total Disks - 3 online Total: 59.08 GB 
KE8 El NODEO2 No disks available Free Space: 13.74 GB 
ca Cluster Shared Volumes 3 In Use Disks - 3 online Percent Free: 23.37 
Storage 
(H 88 Networks 
5] Custer Events 





Cluster Disk 3 





"4 Take this resource offline 
Disk Witness in Guorum BB] Move this shared volume to anothe... b 
(E 4 Custer Disk 1 NODE01 cs Remove from Cluster Shared Volumes 


Custer Shared Volumes u]. Show the aitical events for this res... . 





E Cs Custer Disk 2 (4) Online (Backup in progress, Redirected access)  NODEO1 More Actions. . b 
CACiusterótorageACSV DISK 1 File System: NTFS 29.29 GB (21.87. free ) 


jege rezes te ee ek ÁB KT ea id s Sus] 23.29 GB (22.17 free ) 








ábra 14: A CSV típusú lemezen elhelyezett VM mentése 


Virtuális gépek és a VHD állományok kezelése 


A mentésre kijelölhető elemlistában megtalálható a komplett virtuális gép is, de visszaállítani nem 
biztos, hogy az egész gépet szeretnénk. Olykor nagyon jól tud jönni az a funkció, amit a DEM VHD 
elemszintű visszaállítás képességeként tud nyújtani. A kiválasztott időpontban készült VHD mentést 
képes felcsatlakoztatni, ezáltal tallózható állapotba kerül a virtuális merevlemez tartalma. A többi már 
egyértelmű: visszaállíthatjuk az eredeti virtuális gépbe, vagy alternatív helyre a szükséges fájlokat. Ha 
Windows Server 2008 R2 platformra telepítjük a System Center Data Protection Managert, akkor még a 
Hyper-V szerepkör telepítésére sincs szükség, hiszen ebben az O0S-ben már alapértelmezett a natív vhd 
támogatás. 


Végfelhasználói visszaállítás 


Egy örök dilemma látszik megoldódni az említett funkció bevezetésével. A vállalati üzemeltetés 
alapértelmezettként nem foglalkozik a munkaállomásokon tárolt adatok mentésével. A lokálisan 
tárolandó adatok ellen számos szabályozás és technikai korlátozó eszköz született, de úgy tűnik, a 
felhasználók mindezek ellenére szeretik a gépükön tartani a számukra fontos adatokat. Viszont, ha ez a 
lehetőség adott, akkor meg kell oldanunk ezen adatok központosított mentését is! 

A DPM 2010-ben lehetőségünk van arra, hogy a munkaállomásokon tárolt adatokra egységes mentési 
szabályozást készítsünk, amit a felhasználó saját szabály elemeivel bővíthet, persze csak akkor, ha ehhez 
megadtuk számára a megfelelő jogokat. 
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MI Modify Group - Protected Client Computers 


Steps 


e 


e 


e 


e 


e 


e 


Select group members 
Specify protection rules 


Select data protection 
method 


Select shorttem goals 
Summary 
Status 


specify Inclusions and Exclusions 
Specffy the folders that you want to include or exclude from protection and the file types that you want to exclude 


Specify the folders that you want to include or exclude from protection. 


FEE KET EE EEEN ESES SEVEN ERNE SZE MRGCEK EMEL ÉRE KENEREEL AE CHE EROMÉBL MME Nt HHKHTE KKEOSA BSE BREE 
specific paths. Then choose whether you want to apply the include rule or exclude rule to them. 













Included folders will always get backed up unless they are inside another excluded folder. Excluded folders and their 
sub-folders will not be backed up. For additional details, click here. 












Temporary Internet Files 


[  Allow users to specify protection group members 
Select this option to allow end users to include folders of their choice for protection. Folders you have excluded will not be 
selectable. You must specify at least one include rule to enable this option. 
File type exclusions 


Type the file extensions for example: mp3, wav) that you want to exclude from protection. Use comma "to separate 
multiple file types. These files will not be backed up ff they are in an included folder orin a folder added by an end-user. 


[/dvi. bin. iso. mov, mp3. wavl 














— cBakk [[/ Dos [/ Crcd [/ Hap) 





ábra 15: Munkaállomások vállalati mentési szabálya 


A funkció igénybevétele előtt a desktop gépekre is telepítenünk kell a DEM ügynök komponenst, majd 
meg kell fogalmaznunk a védendő erőforrások körét. Miután a munkaállomáson futó ügynök megkapta 
a szabályokat a folyamat automatizálttá válik. Igény esetén a felhasználó saját igényei alapján 
kiegészítheti a mentendő adatok körét, de a céges szabályozást nem módosíthatja. 


Hi Data Frotectian Manager Client 


Frotected Iterms 


select the folderz you want ta back up. 


(1) 1 The folders in bold are managed by vour backup admirustrator according 
to vour Company Fratection Policy. 


(H-[F] Carpdata 
H-T HTESTE 
(H-T FeríLags 
(H-[F] Fersonal data 
H-T Program Files 
H-T Frograrn Files [4861] 
H-T Fragrarmnl ata 
EH [ElRecasery 
[el Svstem solurne Information 
[- - Users 
EH-[G [7] Admin 
EH: F-Z] administrator 
H-T Lefault 
EH [EIPublie 
[ E- H-[7] zuborz 
fái. n.Fltzindnwa 


Size ot data selected: Calculate 





ábra 16: A mentendő adat körét a felhasználó is befolyásolhatja 
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A visszaállításra a már megszokott előző verziók opció használható: 





GC" di cc Local Disk (CA) b Corpdata p IT Documents j ( General ] Security Custom ] Detai ! Previous Versions 


— File Edit View Tools Help KN 





e Previous versions come from restore points or Írorn 


Organize v íwi Megnyitás v Print New folder Windows Backup. How do I use previous versions? 


nm 


Jr Favorites Name 


HEJ Desktop F] Hyper-V Server Configuration Tool Guide... 
"4. Downloads FI Hyper-V Configuration Tool Guide.docx Name Date modi, — Location 
E) Recent Places W] Hyperv. Deploy.doc 
B Hyper-V. Getting Started.docx 
Libraries B Hypervisor Top Level Functional Specific... 
E Documents B Top 10 Reasons to Upgrade to NW/S08R2,.. 
d Music Understanding Yolurne Activation 2.doc 
Ez] Pictures VHD Test Drive whitepaper V1.doc 
s videos Virtual Hard Disk Forrnat Spec 10 18 06.... 
ra Virtualization sz Owithzsz0Windows5205.,, 
(E Computer LD) Virtualization éz ÜwitheszÜWyindowsz5205.., 
Volume Activation 2 0 Öperations Guide... 
€ia Network Volume Activation 2.0 Deployment Guid... 
[4] Volume Activation 2.0 FAO.doc 


(Aj [doszsaszssssssssssssssssssssssssssszzálászzszszea 
7] Hyperv Deploy.doc Date modified: 2010.1. 
zzz Microsoft Office Word 97-2003 dokumentum 1 Apply 


ábra 17: árnyékmásolatból való visszaállítás 


File versions: 


4 A long time ago (1) 
HypervV Deploy.doc 2008.11.11... — Restore point 











Üüpen Copy... !  Restore... J 
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RemoteFX a Windows Server 2008 R2 SP1-ben 


Napról napra egyre több cég ismeri fel a virtualizációban rejlő Szalay 
előnyöket: a  költségcsökkentési lehetőségeket vagy az Márton 
üzemeltetés egyszerűsödését. A VDI-nek (virtuális desktop 

infrastruktúra) köszönhetően a korábbi költséges vastag EERCSZETETÁGK 
klienseinket olcsóbb vékony kliensekre cserélhetjük anélkül, MCSE, MCITP, 
hogy csökkenne a felhasználói élmény. MCPD, MCT, 


CCNA, Security 
A Microsoft több mint két évvel ezelőtt felvásárolta a Calista . WELL 0 KR 





Technologies nevű, desktop virtualizációval foglalkozó céget. A Calista által kidolgozott technológiákat 
továbbfejlesztették, majd 2010 márciusában bejelentették a Microsoft RemoteFX-et. Ez nem egy új 
termék, sokkal inkább az RDP-technológia kibővítése, továbbfejlesztése. A RemoteFX segítségével a 
távoli asztali kapcsolaton keresztül a felhasználó a megszokott Windows Aero környezetben Silverlight 
és Flash animációkat nézhet, minden DirectX-re és több, OpenGL-re épülő 3D-alkalmazást futtathat, 
médialejátszókat és tetszőleges USB-eszközt használhat — pont úgy, mint a saját, helyi számítógépén. 


Korábban problémát okozott a 3D-s, illetve a grafikát intenzíven használó alkalmazások (pl. CAD- 
alkalmazások, animált weboldalak, videók) virtualizálása, pontosabban ezek hálózaton történő átvitele. 
A RemoteFX ezt a problémát orvosolja. 


Képzeljük el azt a szituációt, hogy egy CAD programot használó, 15 fős tervezői csapattal rendelkező 
tervezőiroda költségcsökkentési céllal konszolidálja a  munkaállomásait és a munkatársaknak 
vékonyklienseket ad. Vesznek egy nagyobb teljesítményű szervert, melyen Hyper-V-ben (akár az 
ingyenesen elérhető Microsoft Hyper-V Server 2008 R2 SP1-en is) futtatják a 15 db Windows 7 SP1-es 
virtuális munkaállomást, a szerverbe pedig vesznek 3-4 db támogatott GPU-val rendelkező videokártyát. 
A RemoteFX akkor jön be a képbe, amikor a tervezők a vékony kliensükről RDP-n keresztül 
bejelentkeznek a nekik fenntartott Windows 7 SP1-es virtuális gépekre és elindítják a CAD programot. A 
gyengébb teljesítményű vékony kliensek valószínűleg nem tudnák futtatni a CAD alkalmazást, de nem is 
kell, ugyanis minden erőforrásigényes műveletet a szerver végez el, a kliensek feladat pedig csak a 
megjelenítés. E feladatokat a RemoteFX az alábbi szolgáltatásokkal támogatja: 


e — Hosztoldali renderelés: Bár az Aero-felületet már a Windows Vistában lévő 6.0-s RDP is át tudta 
hozni, azonban valójában csak a 3D-s grafikai utasítások utaztak az RDP-protokollban és a 
megjelenítést, a kép előállítását a kliens grafikus processzora (GPU-ja) végezte. A RemoteFX 
esetén a virtuális Windows 7-ben futó 3D-alkalmazás 3D utasításait (DirectX, OpenGL) — egy 
virtuális videokártya driver közbenjárásával — a virtuális hosztgép (Hyper-V szerver) valamelyik 
GPU-ja fogja kiszámítani, leképezni, majd a bitképet visszaküldi a virtuális Windows 7-nek, ami 
továbbítja az RDP-csatornán keresztül erős és adaptív tömörítés mellett a vékony kliensnek. Így 
a felhasználó — a vékony kliens teljesítményétől függetlenül, kizárólag a szerver CPU-ját és GPU- 
ját használva - a felhasználói élmény csökkenése nélkül futtathatja a grafikai programokat. 

e — GPU virtualizáció: A RemoteFX egy WDDM driver segítségével elérhetővé teszi a virtuális 
desktop számára a hosztgép (Hyper-V szerver) GPU-ját, így több virtuális munkaállomás 
osztozhat egy videokártya GPU-ján, vagyis egy videokártya egyidőben több munkaállomást is 
kiszolgálhat. 


JŐ 


e — Intelligens képernyőrögzítés: Figyeli az egyes képkockák (frame-ek) között a képernyőt és csak a 
változásokat küldi kódolásra, továbbá monitorozza a hálózati sebességet és a kódolást, illetve a 
képfrissítést a rendelkezésre álló sávszélességnek megfelelően állítja be. 

e . RemoteFX Encoder: A kódolást a processzor, a GPU vagy akár dedikált hardvereszköz is 
végezheti. Amikor a képernyőkép tömörítésre került, az Encoder a keletkezett bitképeket elküldi 
a virtuális munkaállomásnak, ami pedig továbbítja azokat az RDP kliens felé. 

e . RemoteFX Decoder: Dekódolja a virtuális desktopról az RDP kliensre érkezett bitképeket, amit 
szintén akár a processzor, akár a kliens GPU-ja vagy akár egy dedikált hardvereszköz elvégezhet. 

e . RemoteFX USB átirányítás: A RemoteFX a klienshez csatlakoztatott USB eszközöket az USB-busz 
szintjén irányítja át, így a virtuális desktopon anélkül is használhatjuk őket, hogy az RDP kliensen 
drivert telepítenénk hozzájuk. Ez a megoldás támogatja többek között a hangeszközöket, a 
tárolókat (pl. pendrive, hordozható merevlemez), a HID-eszközöket (pl. billentyűzet, egér), a 
nyomtatókat és a szkennereket. 


Szoftverkövetelmények: 


A RemoteFX-et a Windows Web Server 2008 R2 és a Windows Server 2008 R2 for Itanium-Based 
Systems kivételével minden, SP1-gyel frissített Windows Server 2008 R2 változaton használhatjuk, még a 
Microsoft Hyper-V Server 2008 R2-n is! A virtuális desktopon a Windows 7 Enterprise vagy Ultimate 
kiadás SP1-gyel frissített verziójának kell futnia, ellenben RemoteFX-támogatott RDP kapcsolatot 
bármilyen számítógépről kezdeményezhetünk, feltéve, hogy Remote Desktop Connection kliensprogram 
7.1-es változatát használjuk. 


A Windows 7 és a Windows Server 2008 R2 első szervizcsomagjának bétája innen tölthető le. 





Hardverkövetelmények: 


e — SLAT-ot (Second-Level Address Translation, másodszintű címfordítás) támogató processzor, mely 
virtualizáció során jelentősen javítja a teljesítményt. Az Intel processzoraiban ezt Extended Page 
Tables (EPT), az AMD-nél Nested Page Tables (NPT) néven találjuk meg. 

e . A RemoteFX szerverben (virtuális hosztgép) legalább egy, de ajánlott — a használat intenzitásától 
függően — 4-5 felhasználónként, vagyis 4-5, GPU-t használó virtuális gépenként egy GPU. A GPU 
driverének támogatnia kell a DirectX 9.0c-t és a DirectX 10-et. Ha a szerverben egynél több GPU 
van, akkor azoknak egyformának kell lenniük, és megfelelő mennyiségű dedikált — azaz nem a 
rendszermemóriából leválasztott — videomemóriával kell rendelkezniük. Amennyiben használjuk 
a Hyper-V Live Migration szolgáltatását, akkor minden RemoteFX szerverben egyforma 
videokártyákat kell használnunk. Minden, XDDM driverrel rendelkező videoeszközt le kell tiltani 
— jellemzően ilyenek a szerverek alaplapjára integrált távmenedzsment adapterek. 

e . A hardveres RemoteFX Encoder opcionális, de jelentősen javítja a RemoteFX szerver 
skálázhatóságát. A hardveres enkódert egy x4-es vagy gyorsabb PCI-E csatlakozóba kell rakni. 

e — A szervernek meg kell felelnie a Hyper-V által támasztott követelményeknek. 
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A RemoteFX szolgáltatást a szerverre a Server Manager e Kiszolgálókezelő konzolban a Roles e 
Szerepkörök, Remote Desktop Services e Távoli asztali szolgátatások pont alatt telepíthetjük, majd a 
Hyper-V konzolból adhatunk RemoteFX 3D Video Adaptert az egyes virtuális gépeknek. 


További olvasnivalók angolul: 


e . A RemoteFX röviden (videó): http://technet.microsoft.com/en-us/edge/remotefx-in-server- 
2008-r2-sp1-with-michael-kleefe.aspx?guery-1 

e . A támogatott GPU-k listája: http://go.microsoft.com/fwlink/?LinkID-197416 

e . RemoteFX bevezetése lépésről lépésre: http://technet.microsoft.com/en- 
us/library/ff817611(WS.10).aspx 

e — USB átirányítás beállítása RemoteFX-en lépésről lépésre: 
http://go.microsoft.com/fwlink/?Linkld-192431 


e — NVIDIA és a RemoteFX: http://blogs.nvidia.com/ntersect/2010/07/nvidia-and-microsoft- 


enhancing-the-virtual-desktop-user-experience-with-microsoft-remotefx.html 
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Extended Events kezdőknek 


Az SOL 2008 jónéhány újdonságot hozott, ezek közül az egyik 
legalacsonyabb marketing/hasznosság aránnyal rendelkező az 
Extended Events (magyarul kiterjesztett események, de még 
egyszer nem írom le). Ez egy alacsonyszintű eseménykezelő 
rendszer, ami tulajdonképpen egy alapos debug lehetőség SOL 
Serverhez. Az esemény itt egy meghatározott pont a kódban 
(mármint az SOL Server mint alkalmazás kódjában, és persze 
nem egy, hanem sok meghatározott pont van, de valószínűleg 

z ; j 48 é de pá: Vis ha. 28 SOL Server MVP 
nem érdekel minket minden egyszerre), ami érdeklődésünkre ——— 
számot tarthat. Tehát igazi debug lehetőség, csak éppen nem Visual Studio, hanem Transact-SOL kell 
hozzá. 


Bitemo Erik 


Disney Interactive 
Media Group, 
DBA Expert 


MCDBA, MCIS 





Az események sokfélék lehetnek, fájl hozzáféréstől lockok kezelésén át T-SOL utasítások végrehajtásáig 
bármi beleférhet. A megfigyelhető események köre némileg átfedésben van a Profiler vagy SOL Trace 
által figyelhető adatokkal, de az Extended Events sokkal mélyebb betekintést enged az SOL Serverben 
zajló dolgokba, és sok olyan dolgot is meg tud mondani, amit a Profiler soha (például mennyi idő volt egy 
latch megszerzése). És ami igazán lényeges: olyan áron mondja meg, hogy a Profiler/SOL Trace elsápad 
az irigységtől. Egy 2 GHz-es processzoron 2 us alatt dolgoz fel egy eseményt. Ez érezhetően elég kicsi, 
másodpercenként 500000 eseményt dolgozhatna fel főállásban egy processzormag. Itt azért 
megkérdezheti az olvasó, hogy , jó, jó, de akkor miért nem ezt használja mindenki a világon?" . 


Az első és sokaknak legfájdalmasabb válasz, hogy talán azért, mert nincs hozzá grafikus felület. Mindent 
Transact-SOL-ben kell összedobálni hozzá, és ebben az esetben a Books Online is kevesebb példát hoz, 


mint szeretnénk. 
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ábra 18: Extended Events Metadata Viewer 
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Ezt a problémát kiválóan orvosolja Jonathan Kehayias open source és ingyenes Management Studio add- 
inje, az Extended Events Manager, amit a CodePlexről lehet letölteni. Ez egy kicsit áttekinthetőbbé teszi 
a dolgokat, sőt, akár össze is rakhatunk egy eseményfeldolgozó szeánszot, azaz event sessiont a 
segítségével, illetve megnézhetjük azokat, amik már futnak. Az 1. ábrán láthatjuk az Extended Events 
objektumait, illetve a fastruktúra tetejét, ami felvázolja a második választ az olvasó kérdésére: kissé 
összetett a dolog. 


Az Extended Events a hatékonyság érdekében két részre van vágva az elejétől: az engine, azaz az 
eseményfeldolgozó, és a metaadatok, vagyis az, hogy milyen események elérhetőek, azoknak milyen 
tulajdonságaik vannak, milyen módokon lehet gyűjteni az adatokat, stb. A metaadatokat package-ek 
(csomagok) tartalmazzák, amiket be lehet tölteni futásidőben is, így akár saját diagnosztikai csomagot is 
gyárthatnak azok, akik akarnak. Egy package a következő kategóriákba tartalmazó objektumokat 
tartalmazhat: 

e — Events / események: ezeket akarjuk gyűjteni, megfigyelni. A tevékenységekhez tartoznak 
bizonyos saját mezők, amik a rá jellemző információkat tartalmazzák. Pl. lock esetén a tranzakció 
id. 

e — Actions / tevékenységek: Itt tudunk további gyűjtendő mezőket megadni, tipikusan a 
sysprocesses tábla (akarom mondani sys.dm exec sessions és sys.dm exec reguests DMV-k) 
tartalmait innen tudjuk hozzáadni, mivel azok az események nagyobb részénél érdekesek 
lehetnek. 

e — Targets / gyűjtők: Ide kerülnek a gyűjtött események. Az Extended Events elég egyedi gyűjtési 
lehetőségeket ajánl. Ilyen például a párosítás, ahol eseménypárokat lehet gyűjtögetni (pl. lock 
adása-elengedése), és páratlan események keresésére kiváló. Ott van a bucketizer is (szinkron 
vagy aszinkron), ami megadott számú dobozba (az angol szerint vödörbe) dobja szét a beérkező 
eseményeket, maximum eseményszám per vödör paraméterrel. Mellesleg fájlba is tud gyűjteni, 
meg ETW (Event Tracing for Windows) targetet is tud produkálni. 

e — Predicates / tulajdonságok: Ezekkel előszűrhetjük az eseményeket, például csak bizonyos CPU 
használatot elért taskoknál gyűjtünk adatot. 

e — Types / típusok: Ezeket az adattípusokat fogja ismerni az Extended Events engine. 

e . Maps / térképek: ezek felsorolások, amelyek tartalmazzák pl. a lockok típusait, a különféle 
várakozás típusokat, stb. 


Ezek után ránézve a metaadat fára, azt látjuk, hogy három package van betöltve: a package0, az 
sglserver és az salos. És azt is kibökhetjük, hogy a package0O egyáltalán semmiféle eseményt nem 
tartalmaz, szóval akkor mi értelme a létezésének? Nos, az Extended Events igen fifikás szerkezet, a 
betöltött package-ek egy nagy dobozba kerülnek, és az egyik package-ben definiált eseményt a másik 
package-ben definiált target segítségével gyűjthetjük, akár a harmadik csomagban definiált kiegészítő 
tevékenységek megadásával. 


Ezzel az új tudással felvértezve mindent kikövetkeztetünk: a package0O az általános és az ETW-hez 
szükséges metaadatokat tartalmazza: itt található az összes target például. A salos az SOL Server 
operációs rendszerével kapcsolatos adatokat szolgáltatja. (Igen, az SOL Serverben van egy operációs 
rendszer, mert kell neki, mivel sok olyan feladatot, amit egy processznek általában az operációs rendszer 
kezel, az SOL Server maga szeret megoldani. Két tipikus példa a feladatütemezés és a memóriakezelés.) 
Az salserver nevű csomag meg minden mást, amit még kitaláltak. 


Illetve... van egy negyedik csomag is, a SecAudit nevű. Erről azt kell tudni, hogy egy private (magyarul 
privát) csomag, aminek az objektumait nem használhatjuk fel saját event session létrehozása során, és ő 
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csak az Enterprise Editionben (pontosabban Enterprise engine-ben, azaz a developer és az evaluation is 
tartalmazza) található. A művelt és Millenárist megjárt olvasó itt már bólogat: igen, az SOL Server Audit 
saját kis csomagja ez, hiszen az is Extended Events alapú. 


Most, hogy ennyit beszéltünk, nézzünk egy egyszerű event sessiont: 

LE EXISTS(S6EUEET " FROM 8yő.SSÉÍVEi: éVBNLt SESSLŐNS HEGEBE names" Tedhnetbéeme" ) 
DROP EVENT SESSION [TechnetDemol]l ON SERVER; 

CREATE EVENT SESSLON jilechnetbDemől 

ON SERVER 


AB EVENT SOLSStVSC .EtZOT TEPGEÉELSÜ( 
ACTION (sglSétfyver SES8810M 1d, Sglőétveét égi téxt;, SgiSetjvét tegi stack, 
sglserver.username) 


VELEJE 1 [egiőéÉver! s. [dacioasa 1d]j5-T1y1) 
ADD TARGET packadge0 ring bűüirtert 

SET max memory-4096) 
WITH (MAX MEMORY - 4096KB, EVENT RETENTION MODE - ALLOW SINGLE EVENT LOSS, 
MAX DISPÁTCH LATENGY — 1l-SECONDS; TRACK CAUSÁALITT — SEF, STÁARTUP STATE — €EE) 


ALTER EVENI SESSION [Technetbemol]l ON SERVER STATE — START 





Ez elég randának tűnik, de ezt Jonathan kis kütyüjével egyszerűen összedobhatjuk, aztán meg már 
könnyű kézzel piszkálni. Nézzük végig sorban: csináltunk egy új event sessiont, és hozzáadtuk a salserver 
package-ből az error reported eseményt. A standard mezői mellé még a session id, sal text, tsal stack 
és username infót gyűjtjük, szűrőfeltételünk pedig annyi, hogy a database id (ami egy salserverből vett 
predicate) legyen 7, mert nekem az az AdventureWorks. Kell még egy target is, most egy ring buffert 
választottam (természetesen package0-ból), ami pont az, aminek látszik: egy meghatározott méretű 
memóriadarab, amibe tömjük be az adatot, és ha megtelik, a túloldalán kiesik a legrégebbi. A session 
viselkedését befolyásolhatjuk néhány WITH opcióval, ezek közül az egyik legérdekesebb az event 
retention mód, vagyis esemény megőrzés módja. Lehet egy vagy töb veszteséget megengedni, vagy 
mondhatjuk, hogy nem lehet eseményvesztés. Ez utóbbi jó ötletnek tűnik, de ha valami nagyon sokszor 
bekövetkező dolgot választunk sok adattal, akkor még a könnyűsúlyú Extended Events is belerúghat a 
szerverünkbe. A track causality állítja be, hogy a kauzalitást, azaz az ok-okozati összefüggéseket gyűjtse- 
e a session. Ez akkor lehet hasznos, ha több helyről származó adatot szeretnénk összevetni. A 
startup state pedig magától értetődően azt határozza meg, hogy ha elindul az SOL Server, akkor vele 
induljon-e a session. 

Ennyi tudás után generáljunk forgalmat: 


USE AdventureWorks 
SELECI " from AdventureWorks.HumanResources .Department d 
where d.ModifiedDate - -34656456565656 


Msg 8115, Level 16, State 2, Line 1 
Arithmetic overflow error converting expression to data type datetime. 





Majd nézzük meg, hogy mit fogtunk, azaz milyen események vannak a ring bufferben: 


sal ECT CAST(xet. target data AS xmi) 
FROM sys. dm xé S688810n tárgets xet 


LNNER JOLN Sy8.dű Xé. SESSLONS X8 
ON (26 address  —. xet.évent sessLONn addéess) 
WHERE xe.name — "!"TechnetDemo" 
Láthatjuk, hogy nem is egy, hanem két eseményt is elkaptunk: az első a USE AdventureWorksre adott 
válasz, a Changed database context to AdventureWorks". Hm. Ez is egy message, csak olyan alacsony 
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severity szinttel, hogy nem is tekintjük hibának. Elég a 10 feletti severity-ket figyelni, nosza, adjuk is 

hozzá a scripthez ezt a feltételt is: 

TIE EXISTSISELEET " FROM 8Vő. S8rvet event SéSELŐ0Na WHERE names" Téchnethbéma" ) 
DROP EVENT SESSION [TechnetDemo] ON SERVER; 

CBREATE EVENT SESSLON iTechnetbDemol 

ON SERVER 


an EVENT SgLSSTtVéL.GELrOT tEPGÉtSd( 
ACTION (SúüLSéfver.S68810Mű 1d, öglsőeéetvétssgi text, sgiléetvét tegl stdöok, 


sgaglserver.username) 

MEHESSEK 4 [égiS6SÉVEr] . [dacAutuhtáe 1d]-17]) and. Sévétity 2 10])) 
ADD TARGET package0 ring butirer( 

SET max memory-4096) 
WITH (MAX MEMORY -— 4096KB, EVENT RETENTION MODE — ALLOW SINGLE EVENT LOSS, 
MAX DISPATCH LATENCGY — 1l SECONDS; TRACK CAUSÁLITY GEF, OSTARKTUP OTATE — ÚEG) 
ALTER EVENT SESSLON [TechnetDemol ON SERVER STATE SIART 





Most már csak a tényleges hibát kapjuk el, úgyhogy nézzünk bele a kiváló XML kimenetbe: láthatjuk 
benne a tsai stack actiont is. 
caction name "tagi stack" packagecvaglötvar e 
ICtype name-"unicode string" package-"packageO" /5 
ZXvalue:§ő1lt;íÍírame Ni level—!1! 
handle-"0x0200000052DA6E07EB81796A32995BEZ2ED68BBCE433D912" 1ine— "3! 
offsetStart-—-!36! offsetEnd—!-1!/őgt; 


$1t; frame level—!2" 
handl1e-"0x020000000A9A4316O0CSA6GFDF101DC8F793CEDA4AFC7FOOA9 " 1l1ine— "3" 
offsetStart-!8! offsetEnd-—-!-1!/égt;cC/valuez 
£xtext /5 
27 action 





Vastaggal kiemeltem a stack trace lényegét: a két handle segítségével kiszedhetjük az SOL utasításokat, a 
sys.dm exec sg] text DMF segítségével — ez legyen házi feladat mindenkinek (a megoldást majd 
megírom a blogomon :). 


Remélem mostanra azok, akiknek a Profiler már unalmas, megtalálták következő játszótársukat az 
Extended Events személyében. Zárásul még egy érdekes adalék, ami SOLKIlubon jött fel: SOL Expresshez 
nincs Profiler — viszont az Extended Events elérhető abban is, és megadja a szükséges információkat. 
Még egy okkal több amellett, hogy megbarátkozzunk vele! 
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Windows Intune - Felügyelet a felhőből 

2010 őszére már kis hazánkban is minden a felhőről szól, 
Azure, AppFabric, Windows Live, ADFS, Service Bus, BPOS ezek 
a hívószavak - persze a teljesség igénye nélkül. Mit tehet egy 


Gál Tamás 


Microsoft 
: , ; , Do. Magyarország 
ilyen helyzetben egy alapból szkeptikus és konzervatív, viszont 


sokat látott üzemeltetési szakember? Elkezdi megismerni a IT üzemeltetési 


lehetőségeket, amit lehet kipróbál, és a saját tapasztalata szakértő 
alapján óhajt megyőzödni arról, hogy van-e élet a felhőben, és 
Forefront MVP 





ha van milyen ÍS az? 


Mi a Windows Intune? 

e — Röviden: egy webalapú, Silverlight-os kliens PC felügyeleti megoldás. 

e — Vizuálisan: egy light-os SCE (System Center Essentials) konzol, amiben van egy alapszintű, de 
proaktív gépfiók felügyelet, kicsi Group Policy (de nem az!), kicsi WSUS, szoftver/hardver leltár, 
antimalware szoftver (Forefront Endpoint Protection), és egy Remote Assistance a teljes 
távvezérléshez. 

e — Felépítés, stuktúra szintjén: a kliensek bárhol lehetnek, bent az irodában, a telephelyen, vagy 
akár mozgásban (pl. egy notebook). 

e — Konfigurálás, üzemeltetés: 959 a webes felületen, 596 a kliens gépen (igazából a felhasználó 
bevatkozása csak a vezérlés átvétele apropóján szükséges). 

e — Költség: erről nincsenek (még nem is lehetnek) pontos és végleges információim, azonban az 
tuti, hogy a Windows 7 Enterprise és a Forefront Client licenc benne lesz az árban, sőt egyúttal 
az MDOP-ra (Microsoft Desktop Optimization Pack) is előfizethetünk, és ez így együtt már 


igencsak kedvezményesnek tűnik. 





8 https.// MESET E TSSTRT tNTV KEESENBEZERB " Aa jajo[x] B Account Selection (nő 


Sign Out 


£s Windowslntune 


Select Account 
Select the account you want to use. 





Sort by: account name üg Search accounts £ 
0 Adatum o Agent Health o Alerts o Malware Protection o Updates 
a Coho Winery o Agent Health 501 Alerts a Malware Protection A Updates 
a Contoso 3 Agent Health o Alerts 0 Malware Protection 0 Updates 
a Fabrikam (3 Agent Health E Alerts (9 Malware Protection A Updates 
0 Fourth Coffee o Agent Health 501) Alerts € Malware Protection A Updates 














ábra 19 Lehet több gépparkunk (szervezetünk) is a felhőben, és ezek között kapcsolgatni is teljesen egyszerű 


A bétáról 

A cuccról bármi véglegeset mondani egyelőre nem tudok, jelenleg béta állapotban van, annyira, hogy 
Magyarországról nem is lehet elérni. Nekem is csak azért sikerül, mert egy speciális teszt hozzáférésem 
van, amely viszont szépen működik már vagy 2 hónapja. Öt gépet tartok , benne", 4 XP SP2-öt és egy 
Windows 7-et (ebben a konstrukcióban 25 lenne a maximum). Mind az öt egyébként fizikailag egy 
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helyen van, egy klasszikus Windows tartományban, azaz egy 110 kliens gépes, 6 szerveres infrastruktúra 


részeként működik, ergo nem gond ha egy másik névtérnek is tagja a gép, rendeltetésszerűen 
használható ilyen körülmények között is. 


Telepítés, üzembe helyezés 

Nem mondhatni hogy megizzadtam volna a beüzemeléssel és a telepítéssel, hiszen a dolog 
pofonegyszerű volt. Miután kész lett a hozzáférésem beléptem a Live ID-mal a 
https://manage.microsoft.com oldalon keresztül az Intune-ba, majd a cégek közül kiválasztottam azt 


amelyikbe be akartam terelni a klienseimet (a felügyeleti gépen minimum Silverlight 3.0 kell összesen 
ehhez). 


; Netl Kft 
£s Windows lntune etlogon 


Switch to another account I Sign Out I Privacy ] Help 


a v..- 
7 i - 1! Overview ezésdíeüáváti 
) Search all computers 
ve östem ÖVenew ény ze View system status and alerts, and get started with key management tasks 


a 
EE Computers 


Notice Board Tasks 
2! Updates Create Computer Group 
Installing the Windows Intune Client Software 


s he B B 5 View a Report 
] : To download the client software, open the Administration workspace, and then click Client Software Download. as sityáta let 
e Malware Protection 


e FESS Configure Products, Classifications and Auto Approval Rules for Updates Learn About 
For instructions on subscribing to specific update products and classifications, and creating and editing auto approval rules, see the 


Online Communities 
"Updates Administration" topics in the Windows Intune Help. 


Ka) Software Getting Started with Windows Intune 


a. Hicenses System Status 


(E) Policy Malware Protection Updates 


ú Follow-up needed: 2 Malware instances A New updates to 27 Updates 
2 Reports on 1 computer approve: 


éd) mA Protection warnings: 3 Computers 
4. 4 Administration 


Agent Health 


(sé Agents that are not 4 Computers 
reporting: 


Alertsby Type 45 


A 1 Critical Updates Need to be Approved 10/18/2010 1:00:15 PM 

1 Security Updates Need to be Approved 10/18/2010 1:00:11 PM 
2 Investigate New Malware 9/20/2010 12:21:41 PM 

A 1 Investigate Malware Protection Warnings 10/18/2010 11:38:48 AM 


View more alerts by type 





ábra 20: Mondom, hogy egy mini SCE 


Az Administration pont alól letölthetőek a kliens telepítő csomagok (x86, és x64 egyaránt, de nem 
univerzális, hanem egyedi, azaz egy csomag az adott szervezethez van összeállítva), amelyeket le is 


szedtem, és irány a leendő Intune kliensek. Mely gépek lehetnek kliensek? Nincs komoly megszorítás, 
nézzük csak: 


e. Windows 7 Enterprise, Ultimate, és Professional. 
e. Windows Vista Enterprise, Ultimate, és Business. 
e. Windows XP Professional (SP 2; $SP3 ajánlott) 


Hardveres megszorítás sincs, amin elfut az adott OS, az jó lesz. Admin jogosultság kell, és szoftveres 


követelmény is van, de csak az XP SP2 esetén (Forefront Client Security Filter Manager OFE for Windows 
XP SP2 illetve MSXML 6.0 szükséges). 
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Ezek után felraktam az kliens telepítő csomagokat az öt gépre, restart, és nagyon hamar (: 5 perc) már 
be is jelentkeztek és a konzolon is láttam a gépeket. 


Mit lehet csinálni a konzolon? 

Az áttekintő képernyőről (Overview) már egy csomó információ és feladat elérhető (lásd a második 
ábrát), mint például a képernyő alján a Malware Protection alatti figyelmeztetések, vagy éppen a 
frissítésekre vonatkozó riasztások, vagy a tetején a kliens szoftverre utaló link, illetve a mini WSUS 
kezdeti konfigurációs táncára felhívó hivatkozás. 


A Computers alatt csoportokat hozhatunk létre a WSUS-ból ismert módon. Amely gép nincs csoporthoz 
rendelve az a szintén ismerős Unassigned Computers gyűjtőbe kerül. A csoportok egymásba 
ágyazhatóak, és egy gép több csoportnak is lehet tagja. Itt lehet megtalálni az igazán részletes hardver 
leltárt is, az adott gépfiók tulajdonságai között. 


Az Updates alatt megkapjuk a mini WSUS-t, a szokásos lehetőségekkel, illetve kissé szűkítve, merthogy 
nyilván nincs meg minden (pl. minek a lemezkarbantartás, vagy a proxy beállítás, ez nem a mi gondunk 
többé) komponens. 


Malware Protection viszont nincs az SCE-ben, de itt igen. Viszont ez csak a riasztások és a statisztika 
formájában létezik per pillanat, mivel innen semmilyen művelet nem indítható (vagy csak én nem 
találtam meg.) 


Az Alerts szintén ismerős lesz, az összes létező beépített szolgáltatáshoz és megoldáshoz a Malware 
Protection-tól kezdve a Remote Assistance-on keresztül a hardveres problémákig mindenhez kaphatunk 
riasztást (összesen 379 riasztási típus van), hozzárendelhetünk értesítéseket, és egyebek. 
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£s Windows lntune 


Mm § 


/ 


Alerts 


Overview 


dá All Alerts 


Malware Protection 


4 Monitoring 


Microsoft Desktop Applications 
Microsoft Office 2003 
Microsoft Office 2007 
Microsoft Office XP 
Microsoft Windows 7 
Microsoft Windows Server 2003 
Microsoft Windows Server 2008 
Microsoft Windows Vista 
Microsoft Windows XP 

Notices 

Policy 

Remote Assistance 

System 


Updates 


Netlogon Kft 
Switch to another account I Sign Out I Privacy I Help 





View Properties Close Alert View Troubleshooting Information -— (Hb 
Alerts (7) Filters: . None v 1) Search alerts £ 
Name Source Last Modified Alert Leve 
I MM Some Computers Have Protection . Computers With Protection W  10/18/2010 11:3848 AM Warning 
A Critical Updates Needed Critical Updates 10/18/2010 4:00:14 PM Warning 
a Security Updates Needed Security Updates 10/18/2010 4:00:10 PM Warning 
AA — Malware Seen For First Time RemoteAccess:Win32/GhostRz  9/20/2010 12:21:41 PM Warning 
ÁL.  Malware Seen For First Time RemoteAccess:Win32/RServer . 9/20/2010 12:21:41 PM Warning 
k i ) — Installing the Windows Intune Clie Client Download 9/11/2010 1:37:11 AM Informational 
0 Configure Products, Classification: Update Settings 9/11/2010 1:37:11 AM Informational 
Some Computers Have Protection Warnings v 


General Information 


Description: Check whether real-time protection is disabled, malware definitions 
are out-of-date, or a full or guick scan is overdue on computers that 
have protection warnings, and resolve these issues if needed, 


Category: 


Type: 


Malware Protection 


Current Status 
A Alert Level: 
Status: 
Created: 
Modified: 


Investigate Malware Protection Warnings 


Warning 

Active 

10/18/2010 11:2347 AM 
10/18/2010 11:3848 AM 


Repeat count: 2 


Source: 


ábra 21 A riasztások szakasz 


gépenként is láthatjuk a feltelepített szoftvereket. 


Ha a Licenses részen átugrunk, akkor jöhet a Policy szakasz, ahol egyelőre 3 féle házirend 
sablonból válogathatunk, azaz konfigurálhatjuk az Intune Agent-et, az Intune Center-t, valamint 
készíthetünk Windows Firewall házirendeket. Mindezeket röptében, a beállítások megtétele után, 
azonnal le is küldhetjük a kliensekre, a korábban említett csoportok szintjén akár eltérő módon is. 
Azonban jó ha tudjuk, hogy ha a gépek a földön is egy tartományban vannak, akkor a klasszikus 
házirendek felülírják ezeket. Nyilván ezért érdemes lenne ezeket a gépeket egy külön OU-ba tenni és a 
klasszikus GPO-kat blokkolni, vagy WMI-vel szűrni, vagy bármi más módszerrel izolálni - már persze ha ez 


Computers With Protection Warnings 


Megdöbbentő módon a Software pont alatt találjuk a szoftverleltárt, akár egy csoportban vagy 


a célunk. Egyébként a klasszikus házirendek és ezen házirendek között semmilyen kapcsolat nincs. 


a 3 a 


£7 Windows Intune 
ta) ett .—) Edit Policy: MP1 
e. Overview 
a AII Policies SZET 
Malware Protection 
Updates 


ep 
e 
0 
ka 
B 
B 


zj] 


Netlogon Kft 
Switch to another account I Sign Out I Privacy I Help 


Malware Protection 


Malware Protection Service 
ff Enable Malware Protection: .i 
( ) Yes 
(72 No 


(5) Only on computers that are unprotected when Malware Protection is installed 


FT Enable real-time protection: ci 


I No vs 
FE Track resolved malware (days): ci 


(7 7) 


Scan Schedule 


FE Schedule a daily guick scan: ci 
I Yes vi 
Time scheduled: — ]( 2:00 AM v 


WE) Schedule a full scan: Ci 
ess] 


scan Options 


FE) Run a full scan after installation of Malware Protection: Ci 
I Yes 3 


" 


I. Save Policy ] [  Cancel 





Már csak két 


ábra 22 A Malware Protection rész egy Intune Client típusú policy. 


elem maradt az eszköztárból, a Reports (frissítések, licencek és szoftverek) és az 
Administration. Az utóbbi alatt a szokásos beállítások, a jogosultságok (egy szintén Live ID-val rendelkező 
e-mail címet kell megadnunk egy Service Administration szinthez, ami elvileg kissé gyengébb mint az 
eredeti ún. Tenant Administrator, de erről még nem sikerült kideríteni sokkal többet), illetve a riasztások 


és a frissítések opciói találhatóak meg. 


Mit lehet csinálni a kliens alkalmazásból? 


Ugorjunk a kliensre, ahol a kliens szoftver telepítése után egy Windows Intune Center 


parancsikont találunk a Windows Asztalán. Ha ezt elindítjuk, akkor a következő képet látjuk. 
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ES Windows Intune Center 


Me £7 Windows Intune 
gestion 


Uze thiz prodram to start toclz that vou can úuze tü manade your computer . If von need help Ífram vour system administrator , 
regitest remüte assistance. 


Ep Wii 
d8p Windows Update 


Windows Intune Malware Protection 


otart VAándowez Intume Malyeare Pratection ta scan your computer tor maliciouz soffvvare . 


Microsoft Easy Ássist 
ko 


HReguest remote aszzsistance from vour system administrator . 





ábra 23 A Microsoft Easy Assist gyakorlatilag a Remote Assistance 


Itt a legérdekesebb dolog az Easy Assist, amelyre ha egy felhasználó kattint, akkor az admin felületen egy 
Alert aktivizálódik, amely elvezeti az üzemeltetőt az ő gépen egy Easy Assist kliens (EASetup.exe) 
telepítéséig. Ha ez fent van a gépünkön, akkor elfogadhatjuk a kérést és a LiveMeeting szervereken 
keresztül megnézhetjük a kliens képernyőjét, a felhasználó megoszthatja velünk az Asztalát, az 
alkalmazásait, stb., hogy be is avatkozhassunk, de közben cseveghetünk is vele, és még van pár egyéb 
opció is. Mindent a felhasználó kontrollál, tehát garázdálkodni nehéz, ellenben az látszik, hogy fontos 
volt, hogy a felhasználó tudja kezelni (plusz az egész kliens alkalmazás már most is magyarul van). 


Mikor készül el a Windows Intune? 

Elvileg a jövő év (2011) közepe a cél, ergo ez egy abszolút korai bemutatkozás, ezért újra jelzem, 
hogy még sok-sok minden változhat Intune ügyben, de ami van, az nekem per pillanat ígéretesnek tűnik. 
Jópár leírás és videó viszont elérhető már most is, a http://www.windowsintune.com címen. 
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System Center Configuration Manager 2007 R3 


Lassan több mint 16 év telt el az első Microsoft alapú Horváth Ottó 
rendszerfelügyeleti megoldás megjelenése óta, bár kétlem, 
hogy túl sokan emlékeznének az akkor még Systems Grepton 

, , , : Informatikai Zrt. , 
Management Server (SMS) 1.0 néven futó csodára. Annyira Support Engineer 


régi a termék, hogy még az interneten kutakodva is 
meglehetősen nehéz információkhoz jutni vele kapcsolatban. 
Az azért mindenképpen látszik, hogy a központi menedzsment 





. ; .. 4. 1 E § i Group Policy MVP 
infrastruktúra ötlete nem egy új keletű dolog. Az évek során KE AES s 


persze rengeteget változott a termék, de azt hiszem az SCCM 2007-ben ért el olyan formát, amelyről 
már bizton állíthatjuk, hogy egy kiválóan hatékony és skálázható konfigurációmenedzsment eszköz. 
Természetesen az SCCM 2007 is folyamatosan fejlődik, az elmúlt három év alatt kettő javítócsomag és 
egy kiegészítő csomag jelent meg a termékhez. Jelen cikk apropója nem más, mint a második kiegészítő 
csomag megjelenése, amely az R3 jelölést kapta. 


Minek is nevezzelek? 

A kérdés nem csupán költői, ugyanis még sokat látott rendszermérnökök számára is elég megtévesztőek 
tudnak lenni az SCCM 2007-hez kiadott kiegészítések, frissítések elnevezései, főleg ha azt is megnézzük 
időben miként követték egymást a megjelenések. 


Az R3-ról tudni kell, hogy hasonlóan elődjéhez, nem egy javítócsomagról inkább egy kiegészítőről van 
szó, amely új szolgáltatásokat ad az SCCM képességeihez. A kiegészítő csomagok, tehát az R széria 
telepítése úgymond opcionális, azaz csak akkor szükséges telepítenünk őket, ha a bennük rejlő új 
szolgáltatásokat szeretnénk használni. 


Ettől szinte teljesen független a szervizcsomagok megjelenése, melyek nagy lélegzetvételű főként (de 
nem kizárólag) javításokat tartalmazó csomagok. Telepítésük az erősen ajánlott kategóriába tartozik. 


Mivel a kivétel erősíti a szabályt, az R3 csak SP2-vel ellátott SCCM szerverekre telepíthető, tehát itt 
mégis összekapcsolódik a két dolog. Az ok nagyon egyszerű, az R3 új funkcióit kliens oldalon csak az SP2- 
vel frissített kliens ügynökök tudják kezelni. 


Type: Prirnary 

version: 4,00.6457 2000 
R3 Installed:  "msseeseemljjjíjne- Ves 

Build number : 6487 

Site server: 5001 

SŐL server; 5601 

SMS Provider location: 5C01 
Installation directory: EJSCCM 

Parent site; Noone 


ábra 24: R3 telepítve 


Összefoglalva, a legfrissebb SCCM 2007 verzió jelenleg az SP2-vel frissített, a legtöbb szolgáltatást 
tartalmazó pedig az SCCM 2007 S$P2 R3. Természetesen az R3 tartalmazza az R2 minden szolgáltatását is, 
így nem szükséges azokat külön telepítenünk. 
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Az R3 eszközkészlete 


Energiagazdálkodás 

Az SCCM 2007 R3 segítségével képesek vagyunk teljes körűen szabályozni az SCCM felügyelete alá vont 
klienseink energiagazdálkodási beállításait, ezen felül kimutatásokat is készíthetünk szervezetünk 
energiahasználatáról. 


Hogyan működik? 

Alapjában véve az energiagazdálkodási funkció az SCCM hardverleltárára épül, ezért ennek 
engedélyezése és megfelelő konfigurációja elengedhetetlen a szolgáltatás használatához. A telepítés 
során az R3 kibővíti az SMS DEF.mof tartalmát az újonnan érkező osztályokkal, a fájlokat viszont nem 
cseréli le, így a mof fájl egyedi beállításai nem vesznek el. Ennek ellenére érdemes a mof fájlokat 
elmenteni a telepítés előtt. A funkció használatát két komponens teszi lehetővé, a kliens ügynök illetve a 
definiált energiagazdálkodási beállítások. Először magát az ügynököt kell engedélyeznünk a szokásos 
módon: 


Power Hanagement Client Agent Properties XI] 





Power Management €lient Agent 


( !  Enable power management on dients j 





Cancel [7 érek [0 Hep ] 


ábra 25: Az ügynök engedélyezése 





Ezek után kezdhetünk hozzá a kívánt beállítások testre szabásához, melyeket a kollekciók tulajdonságait 
módosítva érhetünk el. Mindenképpen érdemes új kollekciókat létrehozni az energiasémák 
menedzseléséhez, legalább egy engedélyező és egy tiltó szabályt tartalmazót. 
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all Windows 7 Systems Settings esel 


Maintenance Windows . Power Management ] Collection variables ] Ad: 4 lo] 


specify power management settinags for computers in this collection. 





Enable power management settinas 


(a Hever apply power management settings to computers in this 
collection 


(  Specdify power management settings 





Deal miarsi A elarurart ér ar Énsbűz 
Peak plan: salanced (Configfác " 





tdor-peak plan; 








—-Peak time 








ne [tb] 


ábra 26: Energiagazdálkodás 


A tiltó szabályt alkalmazó kollekcióra azért lehet szükség, mert amennyiben egy számítógép esetleg több 
olyan kollekciónak is tagja, amely energiasémát szabályoz, a , never apply" beállítás minden esetben 
megtiltja az energiasémák központi szabályozását. 


Amint a képen is látható, lehetőségünk van megadni mely időszak jelenti számunkra a munkaidőt és 
ennek megfelelően különböző sémákat definiálhatunk. Ezen felül meghatározhatjuk mikor ébredjen fel a 
számítógép, amennyiben mondjuk éjszakai frissítést, programtelepítést vagy egyéb karbantartási 
műveletet szeretnénk végezni a számítógépeken. Felmerülhet a kérdés szükséges-e a WOL a gépek 
felélesztéséhez. Szerencsére nem, az itt beállított idő a BIOS időzítőjén alapul, amelynek segítségével 
például a BIOS-ban beállított időben is felébred a számítógép. Az időzítő mindaddig működik, amíg a 


számítógép tápellátást kap. 


Érdemes egy pillantást vetni a sémák részletes beállításaira is, mivel szerencsére a lehetőség tárháza 
meglehetősen széles. 
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ered eurázsiai ia í Lt ése 





Name: 


w On battery Plugged in 


fa sleep after (minutes) 


E Reguire a password on wakeup Bv Yes 
Hibernate after (minutes) 5— ah — a 


öllovs hybrid sleep 
Power button action Shut down 1] Shut down s] 


Sleep button action 








Turn off hard disk after (minutes) 





Lid close action 


Start menu power button 





Critical battery action 





Low battery notification level (55) 





51/B1/B1/81/ Bi S0151/81/ 511 B (TÓ 


v ] critical battery notification level (949) 


Löw (Low battery notification notification 


Low battery action Do mee BE Do nothing ml 
öllow standby state when sleeping action eljon 


3 








ábra 27: A sémák részletes beállításai 


Fontos megjegyezni, hogy minden egyes kollekciónál beállított séma egyedi az adott kollekcióra 
vonatkozóan, tehát hiába ugyanazt a nevet látjuk a sémánál, az mindig csak az adott kollekcióra 
érvényes, nem pedig az összesre ahol energiagazdálkodást szabályozunk. 


Érdekesség, hogy míg Windows 7 kliensek esetében a felhasználó tudja módosítani a beállításokat, 
Windows XP esetében erre nincsen lehetőség. Egyelőre nem derült ki, hogy programhibáról vagy 
tervezett működésről van-e szó. Természetesen Windows 7 kliensek esetében is csak addig maradnak 
érvényben a változtatások, amíg nem frissül a központi konfiguráció az SCCM szerverről. A megszokottól 
eltérően a művelet minden 24 órában egyszer történik meg, nem pedig minden házirend frissítéskor. 


Jelentések: 

Amennyiben elvégeztük a szükséges konfigurációt, bizonyára szeretnénk kimutatások formájában látni 
milyen megtakarítást érhetünk el az egyes konfigurációkkal, jelenleg mennyi energiát emésztenek fel a 
klienseink. Természetesen az SCCM riportjai biztosítják mindezen információkat, azonban pár dologra 
nem árt figyelnünk. 


Az SCCM 2007 R3 riportjai csak és kizárólag az SOL Reporting Services funkciójával érhetőek el, a 
klasszikus beépített kimutatásokkal nem tudjuk megjeleníteni őket. Amennyiben tehát szeretnék az 
újonnan megjelent funkciókat is használni mindenképpen engedélyeznünk kell a , Reporting Services" 
használatát, azonban egyébként is ajánlott az SOL-es megoldás használata, mivel a következő verziókban 
mindenképpen ez lesz az egyetlen elérhető megoldás. Amennyiben engedélyeztük a , Reporting 
Services" támogatást, egyetlen dolgunk, hogy importáljuk az SCCM R3 riportjait. A szükséges .cab 
állomány a telepítőkészlet , ReportsiPower Management" könyvtárában található. Amint megtörtént az 
importálás, máris elérhetjük az energiagazdálkodással kapcsolatos jelentéseket. 
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e. öystem Center 
I i ration Manager 2007 








Parameters: 
Report Start Date: 1/20/2010 Report End Date: 3/18/2010 
Collection Name: Main 23 upgrade Collection Current Total Number cf Computers in the Collection: 8416 


Device Type: All Devices 





3596 


2697 


1798 


899 


Number of Computers 





ábra 28: Jelentések 


Utolsó megjegyzés az energiagazdálkodással kapcsolatban, hogy csak kliens operációs rendszerek 
esetében érhető el, a szerverek energiagazdálkodásának szabályozása jelenleg nem lehetséges, de azt 
hiszem nem is ez a funkció célja, ami persze nem zárja ki azt, hogy a jövőben esetleg megjelenik ez a 
lehetőség is. 


Egyéb újdonságok: 


Delta AD Discovery 

A már jól ismert AD System Discovery feladat kiegészítéseként megjelent a Delta AD Discovery, melynek 
segítségével egy korábbi teljes felderítés óta bekövetkezett változásokat kérdezhetjük le. Előnye, hogy 
jóval gyakrabban futtatható a címtárban történt változások keresése céljából, mivel kevésbé terheli az 
AD infrastruktúránkat, mint a teljes szinkronizáció, hiszen nem szükséges minden objektum minden 
paraméterének lekérdezése. 


Dyanamic Collection Updating 

A kollekciók tartalmának frissítése normál esetben szintén 24 óránként történik meg, amely főként az 
operációs rendszer telepítési folyamata, illetve az első ügynöktelepítés után okozhat sok fejfájást az 
SCCM-t üzemeltető rendszergazdáknak. Ennek következtében akár az is előfordulhat, hogy egy 
dinamikus kollekcióra kihirdetett program csak egy nappal az ügynök telepítése után kerül ki a 
célcsoport klienseire. Ezt a problémát igyekszik orvosolni a dinamikus kollekció frissítés, mely az alábbi 
négy esetben használható: 
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e — Első alkalommal felderített rendszerek esetén 

e — OSD eljárással telepített kliensek első felderítésekor 
e — Első hardverleltár készítése során 

e ". SCCM kliensek verziójának frissítése után 


A fentiektől eltérő esetekben a normál kollekciófrissítési metódus érvényes. 


PreStaged Media 

Az SCCM szoftvertelepítési képességét használók számára biztosan ismerős már a PreStaged vagy más 
néven OEM média fogalma, hiszen az MDT integrációval már elég régóta elérhető ez a típusú telepítés 
eljárás az SCCM-ben. Az R3-ban viszont már natív SCCM képességgé vált az OEM telepítőkészletek 
készítése, azaz létrehozhatunk egy olyan telepítőkészletet amelyet előtelepíthetünk a kiszemelt 
klienseinken, majd a telephelyre szállítva erről az állapotról folytatódhat a telepítés a különböző 
szekvenciák futtatásával. Azaz megspóroljuk magának az alap lemezképnek (WIM fájlnak) a hálózaton át 
történő telepítéséhez szükséges időt. 


Előfeltételek 

Az R3 telepítéséhez minimum SCCM 2007 SP2-re van szükségünk ugyanis az új képességek 
használatához az SP2-es verziójú kliens szükséges. Továbbá szükségünk lesz a KB977384 jelzésű javításra, 
mind a szerveren mind az összes felügyelni kívánt kliensen. A javítócsomag telepítésekor a varázsló 
segítségével automatikusan létrehozhatjuk a javítás terítéséhez szükséges csomagot és programot is. A 
hirdetmények létrehozása és kollekciókhoz rendelése a mi feladatunk marad. 
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Operációs rendszer telepítés SCCM használatával - 1.rész 


2, Vh , Horváth Ottó 
Az operációs rendszer telepítésről általában 
Amint a címből is kitűnik a következő rövid leírásban az Grepton 
operációs rendszer telepítésről lesz szó, természetesen nem a HOTÓELHALÍSAL ZE s 
Support Engineer 


hagyományos , értelemben vett Windows telepítőlemezes 
,kattintgatós" telepítést fogom részletezni. 





Milyen telepítési metódusokat is ismerünk? 
Az otthoni felhasználók esetében megszokott az úgynevezett telepítőlemezes telepítési eljárás, amikor a 


ALT a" ERR Group Policy MVP 
Windows lemezünket használva a varázsló segítségével telepítjük az operációs rendszert. Természetesen 
egy vállalati, főleg nagyvállalati környezetben nem alkalmazható több okból sem. 


Telepíthetjük az operációs rendszert előre elkészített lemezképeket felhasználva is, néhány évvel ezelőtt 
erre egy elfogadott módszer volt például a Symantec Ghost és hasonló alkalmazások használata. A 
megoldás előnye, hogy a lemezkép tartalmaz minden szükséges beállítást és alkalmazást, de a 
testreszabhatóság és a dinamikus telepítőkészlet készítés nagyon korlátozott. Másrészt ezen módszerek 
egyáltalán nem támogatottak illetve Windows Vista utáni rendszerek esetében rengeteg kompatibilitási 
problémát okozhatnak, ezért nem is ajánlottak. 


A harmadik típusú eljárás az automatizált telepítés, melynek megkülönböztetjük két válfaját, melyeket 
LTI és ZTI betűszavakkal szokás jelölni. Az LTI (Lite Touch Installation) típusú megoldásokkal kis emberi 
beavatkozással tudjuk nagyszámú kliensre telepíteni az operációs rendszert, ZTI (Zero Touch Installation) 
metódus esetében egyáltalán nem szükséges emberi beavatkozás a telepítési folyamat közben, azon 
kívül, hogy távolról elindítjuk az eljárást. 


A Microsoft rendszerek világában a LTI eszköze az MDT (Microsoft Deployment Toolkit) amely egy 
dokumentációkat, automatizmusokat, menedzsment eszközöket magában foglaló csomag, mely a WAIK- 
re, WDS-re épülve lehetővé teszi az operációs rendszerek tömeges telepítését. 


A ZTI eszköze, mely a cikk témája is lesz, elsősorban a SCCM, amely magában is képes a ZTI típusú 
telepítések elvégzésére. Azt viszont mindenképpen tudni kell, hogy a maximális testreszabhatóság és a 
legszélesebb funkciókészlet használatához a SCCM és a MDT együttes alkalmazása javasolt. Ugyanis az 
MDT nem csak az LTI, de a ZTI módszerhez is tartalmaz eszközöket, viszont ezek mindegyike a SCCM-re 
épül. 


Milyen feladatokat valósít meg az automatizált operációs rendszer telepítési 
képesség? 
Az SCCM és MDT integrációja a következőket teszi lehetővé számunkra: 


e — Telepítőkészlet elkészítése és testre szabása beavatkozás nélkül 

e — Alkalmazások integrálása a telepítőkészletbe meghatározott szabályok alapján 

e — Operációs rendszer telepítése és teljes körű testre szabása meghatározott szabályok alapján 
e — Operációs rendszerek migrációja, felhasználói adatok mentése és visszatöltése 
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e — A migrációt megelőzően biztonsági mentések készítése 

e "A korábbi operációs rendszer virtuális géppé konvertálása és azonnali csatlakoztatása Windows 
VPC-vel 

e — Aktuális frissítések integrálása a telepítési folyamat közben 

e — Automatikus driver telepítés 


Amennyiben egyszer elkészítettük a telepítési eljárást, minden automatikusan történik további emberi 
beavatkozás nélkül. Leszámítva persze a hibakezelést. 60 


A gyakorlat - Első lépesek 

Ugyan rendelkezem már egy éles infrastruktúrával ahol a következőkben ismertetésre kerülő eljárás 
tökéletesen működik és több éles bevetésen is bizonyított már, a hitelesség és a demó kedvéért 
kiépítettem virtuális környezetet ahol lépésről lépésre bemutatom az OSD képességhez szükséges 
eszközök telepítését és konfigurálását. Így remélhetőleg egyetlen lépés sem fog kimaradni, hiszen én is 
lépésről lépésre a leírtakat követem. 


Ahonnan elindulunk: 

A kezdéshez kialakítottam egy nagyon egyszerű SCCM infrastruktúrát, amely mindössze egyetlen 
központi szerverből és néhány kliensből áll. Az operációs rendszer Windows Server 2008R2, melyre egy 
SOL Server 2008R2 került. 


Megjegyzés, éles környezetben is ajánlott az SCCM szerveren elhelyezni az SOL adatbázist, akármennyire 
is furcsán hangzik. Az SCCM rengeteg adatbázis műveletet végez működése során, ezért kiemelten 
fontos, hogy az SOL adatbázis elérése minél nagyobb sebességű legyen. Viszont azt kell mondanom, ez 
hálózaton keresztül az esetek nagy többségében lassabb, mint a helyi szervert használva ahol a 
memórián keresztül tudnak kommunikálni a komponensek. Ezt a sebességet semmilyen hálózati adapter 
nem tudja biztosítani. A Microsoft ajánlása alapján a dedikált szerveren üzemeltetett SOL nagyobb 
teljesítményt biztosít, de valójában csak 100k számítógép felett válik erősen ajánlott konfigurációvá a 
szeparálás. Természetesen ebben az esetben dedikált minimum gigabites kapcsolat szükséges. 
Tapasztalataim alapján még a magyar viszonylatban nagyvállalatok esetében is gyorsabb a site szerveren 
futó SOL-es megoldás, mint a különválasztott infrastruktúra, természetesen a Site szerver 
számítógépnek megfelelő erőforrásokkal kell rendelkezni, ami SOL esetében főleg nagyon sok memóriát 
jelent. 8GB alatt nem érdemes próbálkozni a legkisebb környezetekben sem. Ö 


Szóval vissza a demó környezethez. Az operációs rendszer és adatbázis telepítése után felkerült a SCCM 
2007 SP2-es verziója majd az R2 is. A Windows 7 terítéséhez mindenképpen szükséges mind az SP2 mind 
az R2, előbbi a Windows 7 támogatáshoz, utóbbi az ismeretlen számítógépek támogatásához. A 
telepítést követően csak a legfontosabb dolgokat konfiguráltam, úgy mint felderítési módok, , Network 
Access Account", kliens terítés, ,boundaries", Egy korábbi cikkemben már említettem, milyen 
problémákba ütközhet az ember, ha figyelmetlen a telepítés közben: 


SCCM 2007 telepítés, ahol a varázsló kevés 
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Ha minden rendben, az SCCM működik, a kliensekre települt az ügynök, kommunikálnak is egymással, 
jöhet az OSD környezet előkészítése. 


Komponensek telepítése 
Az első és legfontosabb teendőnk a PXE Service Point telepítése, mely gyakorlatilag egy normál PXE 


szolgáltatás kombinálva egy kis WDS-sel. Nagyon fontos, hogy a lépéseket pontosan kövessük, mert 
amennyire egyszerűnek látszik a dolog annyi hibát tud okozni a későbbiek során, ha az elején elrontjuk a 
telepítést és az alapbeállításokat. 


Első lépésben telepítsük a WDS szolgáltatatást a szerverünkre. A telepítés után ne konfiguráljuk be a 
WDS szolgáltatást, ne próbáljuk meg elindítani a services.msc-ből, csak hagyjuk abban az állapotban, 
ahogy a varázsló konfigurálta. 
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ábra 29: WDS telepítés 
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Jöhet a PXE service Point telepítése 
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The PXE service point hosts boot images and responds to PXE reguests Írom Configuration Manager 
dients to download those mages. 


[7 Allow this PXE service point to respond to incoming PXE regyests 

7 Enable unknown computer support 

[7 Regure a password for computers to boot usng PXE 
Password: 


C Respond to PXE reguests on al network interfaces 
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ábra 30: PXE service point telepítés 
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e — Allow the PXE service point to respond to incoming PXE reguests 
Ez a beállítás engedélyezi, hogy a PXE szerepkör egyáltalán válaszoljon a hálózati kliensek felől 
érkező PXE kérésekre, tehát mindenképpen szükséges beállítanunk. 


e . Enable unknown computer support 
Az ismeretlen számítógépek támogatása abban az esetben jöhet jól, ha nem szeretnénk az 
újonnan vásárolt, SCCM-et még soha nem látott gépeink MAC vagy GUID számát felvinni az 
SCCM-be a telepítés megkezdése előtt. Az opció bekapcsolásával minden ismeretlen 
számítógépen elindul a PXE boot és megfelelő konfiguráció esetén a telepítés is. 


e — Reguire a password for computers to boot using PXE 
Amennyiben az ismeretlen számítógépek támogatását engedélyeztük, nagyon fontos ennek a 
korlátozásnak a használata is, mivel nem szeretnénk ha egy véletlen hálózati boot után a 
klienseink magukra rántanának egy új Windows verziót, ezért követeljük meg a 
felhasználónévhez és jelszóhoz kötött telepítést. 


A telepítés sikerességét a pxesetup.log fájlban ellenőrizhetjük. Sajnos a varázsló sok esetben akkor is 


sikeres telepítést jelez, ha bizonyos részfeladatok vakvágányra futottak a telepítés közben. 


ÜTZEZTTEZEZT eb ÉÜüKE -181.xl 
File Edit Format View Help 

209-21-2010 23:03:463. ————————————————————————————————— mmm mm 

209-21-2010 23:03:463 SMSPXE Setup Started. 

09- 21- 2010 23: :03: :462 Parameters: C: NPROGRALZÁMTEO96-1N binYi386ROLESE-1.EXE /install]l /siteserver : SCCMLAB SMSPXE 





209-21-2010 23:03:465 No versions of MSXML60 are installed. would install new MSXML60. 

09-21-2010 23:03:465 Enabling MSI Jogging. msxm16 x64.msi will log to c:YProgram Files (x86) Microsoft conrigurattán .Managei 
09-21-2010 23:03:46- Installing c:YProgram Files (x86) wicrosoft configuration ManagerdbinN 1X641000004091 msxm16 x64.m 
209-21-2010 23:03:465 msxml6 x64.msi exited with return code: 0 

209-21-2010 23:03:465 msxml6 x64.msi Installation was successful. 

209-21-2010 23:03:46- ------—— Completed Installion of Pre Regs for Role SMSPXE ——————— 

209-21-2010 23:03:465 Installing the SMSPXE 

209-21-2010 23:03:46: Machine is running Windows 2003 sPl or later. (NTVersion-OX601, Servicepack-0) 

209-21-2010 23:03:465 WDS Service is installed. 

209-21-2010 23:03:465 No versions of SMSPXE are installed. eses lttag new SMSPXI 








209-21-2010 23:03:465 Enabling MSI logging. pxe.msi will log to c:XProgram Files. (x86) Microsoft configuration Manager ) ete 
209-21-2010 23:03:465 Installing c:NProgram Files (x86) Wicrosoft configuration ManagerdbinYVi386pxe.msi CCMINSTALLDIR-—"C 
209-21-2010 23:03:545 pxe.msi exited with return code: 0 

09-21-2010 23:03:545 Installation was successful. 
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ábra 31: Pxesetup.log 


Az így elkészült infrastruktúra alapjában már használható lenne az operációs rendszer telepítési 
képesség használatára, azonban a magasabb fokú testreszabhatóság és az egyszerűbb kezelhetőség 
miatt néhány további kiegészítő telepítése ajánlott. 


MDT 2010 

Az OSD képesség teljes kiaknázásához kimondottan ajánlott az MDT telepítése, amely önmagában is 
használható operációs rendszerek telepítésére, azonban csak LTI módszerrel. Mi viszont ZTI megoldást 
szeretnénk, hiszen ezért is használjuk az SCCM-t, így az SCCM - MDT páros a barátunk. A telepítés 
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meglehetősen egyszerű, amit nem szabad elfelejteni az a telepítés végén az integrációs varázsló 
futtatása, ugyanis ezzel regisztráljuk be a szükséges komponenseket az SCCM-be. 


A folytatás... 
Ezen a ponton el is érkeztünk oda, hogy rendelkezésünkre áll az OSD képesség használatához szükséges 


infrastruktúra, de természetesen még rengeteg lépés van hátra ahhoz, hogy csak hátradőlve várjuk a 
Windows telepítések elkészültét. A telepítési folyamatot az SCCM-ben és az MDT 2010-ben is egy 
úgynevezett Task Seguence írja le, amely gyakorlatilag nem más, mint a telepítési folyamat egymást 
követő lépéseinek meghatározása, egy folyamatábra, ha úgy tetszik. A cikk következő részében ezen 
folyamatleírások készítését és alkalmazását fogom bemutatni. 
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SCCM v.Next 


Azt hiszem a System Center termékcsalád és annak Horváth Ottó 

konfigurációmenedzsmentért felelős tagját senkinek nem kell 

bemutatnom. Ha nem is üzemeltetünk mindannyian SCCM-et Grepton 
hl , h, ; , o, : Informatikai Ztrt., 

napi szinten, de legalább előadások, cikkek révén biztosan Support Engineer 


mindenki kapcsolatba került már vele. A termék régóta jelen 
van a piacon, nagyon sok változáson és komoly átalakításon 
ment keresztül és ez a jövőben sem lesz másként. A napokban 





j db za dől ő . ki § i G Policy MVP 
jelent meg a SCCM 2007 R3-as kiegészítő csomagja, és már —————— EZEEE sost 


javában készül a következő generáció is, mely jelenleg v.Next kódnévre hallgat. A következőkben ezen 
verzió újdonságairól lesz szó, nagyrészt csak elméleti síkon, mivel az első béta verzió csak az újdonságok 
kis részét tartalmazza, ezért a gyakorlati bemutatás még nehézkes lenne. 


Mi változott? 

A jelenlegi információk alapján úgy tűnik, hasonló léptékű változásnak lehetünk szemtanúi, mint 
korábban az SMS 2003-ról SCCM 2007-re történő váltás során. Természetesen a termék alapvető 
felépítése most sem változik lényegesen, az viszont már most nagyon jól látszik, hogy a terméket egy új 
szemléletmód mentén próbálták kialakítani. 


Felhasználó központú menedzsment 

A V.Next-ben a kliens központú menedzsment szemléletmódot egy sokkal inkább felhasználó központú 
szemléletmód váltja fel, azaz minden menedzsment eszköznek és eljárásnak az alapja maga a felhasználó 
lesz, ellentétben a korábbi inkább számítógép központú felfogással. Ez segíti mind a felhasználókat mind 
az üzemeltetőket, előbbieket abban hogy az alkalmazásokat és konfigurációs beállításokat egyszerűen és 
hatékonyan eljuttassák a célfelhasználókhoz, utóbbiakat pedig abban hogy ezen konfigurációs 
paraméterek, alkalmazások minden esetben kövessék őket attól függetlenül, hogy pontosan milyen 
földrajzi helyről vagy milyen eszközről dolgoznak éppen. 


Rugalmas alkalmazás terítés 

Az előzőekben említett felhasználó központú menedzsment megvalósításának egyik eszköze az 
úgynevezett rugalmas alkalmazásterítés, amely képessé teszi a rendszert arra, hogy intelligens módon 
különböző rendszerállapotokra reagálva különböző módokon juttassa el a felhasználókhoz a nekik 
szükséges konfigurációs paramétereket, elsősorban alkalmazásokat. Mindezt egy új alkalmazásmodaeli 
használatával valósítja meg, melyben minden alkalmazást csak egyetlen alkalommal szükséges definiálni, 
majd azokat különböző csatornákon keresztül tudjuk telepíteni, például virtuálisan, prezentációs 
szerverek felé, vagy a hagyományos . alkalmazásterítési eljáráson keresztül. A folyamat során 
megkülönböztetésre kerülnek a felhasználók elsődleges illetve másodlagos eszközei, melyek a számukra 
megfelelő módon kaphatják meg az adott alkalmazásokat. Egyszerűbben mondva, a szerver képes 
eldönteni, hogy az adott eszközünk számára milyen módon juttatható el az adott alkalmazás és a 
lehetőségek közül a legoptimálisabb módot fogja választani. Amennyiben az adott eszközre például nem 
telepíthető egy alkalmazás, azt eljuttatja virtuálisan vagy akár streaming segítségével. 
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Igény szerinti alkalmazás elérés 

Szintén a felhasználó alapú megközelítés ismérve, hogy a végfelhasználók számára elérhetővé tehetünk 
egy önkiszolgáló felületet, melyen kiválaszthatják a publikált alkalmazások közül azokat melyek 
számukra szükségesek, majd elindíthatják annak telepítését. Ezzel jelentősen csökkenthető az 
alkalmazásigénylések miatt keletkezett helpdesk bejelentések száma és ezáltal az üzemeltetők 
ráfordításai is. 


Egységes menedzsment felület 
A jövőben a Configuration Manager felülete lesz az a felület ahonnan minden menedzsmenttel 
kapcsolatos terméket és funkciót koordinálhatunk, és itt most nem kizárólagosan az SCCM képességeire 


e7Z7Ze.e7 


képes megvalósítani: 


e — APP-V 
e . Med-V 
e — Citrix Xen App 


Továbbá az sem titok, hogy a korábban Mobile Device Manager néven ismert szintén a System Center 
család részét képező mobil eszközök kezeléséért felelős termék teljes egészében beolvad az SCCM alá, 
illetve a Forefront Endpoint Protection 2010 is kizárólag az SCCM-en keresztül lesz használható. 


Megfelelőség 

A V.next-től kezdődően a kliens oldalon is megjelent a megfelelőség ellenőrzésének lehetősége, azaz 
meghatározhatunk klienseink számára egy olyan kívánt állapotot melytől való eltérést monitorozhatunk 
illetve automatikusan korrigálhatjuk azt. A szolgáltatás kísértetiesen hasonlít a Windows Server 2008- 
ban megjelent NAP lehetőségre, ahol a kliensek állapotától tehettük függővé a hálózati hozzáférésüket. 
Ezzel együtt megjelenik az úgynevezett öngyógyító kliens fogalma is, melynek használatával klienseink 
egészségi állapota akkor is korrigálható, amennyiben magát a kliens ügynököt már eltávolították az adott 
eszközről. Egyelőre nem teljesen tisztázott miként fog működni ez a funkció, de nagyon érdekesnek 
hangzik, remélem egy következő béta verzióban már több részletet is megtudhatunk. 


Adminisztráció 

Ha ránézünk a következő képre, látható, hogy radikálisan megváltozott az SCCM menedzsment felülete 
és azt is elárulhatom, ez még nem a végleges megjelenése a konzolnak. Például a második béta 
verzióban máris másként fest. Ahogy megfigyelhető, különböző kategóriákba szedve és funkciók szerint 
csoportosítva érhetőek el a különböző opciók, nem a korábban megszokott ömlesztett fa struktúrában. 
Azt hiszem, mondhatjuk, hogy a funkciók bővülése során egyre inkább átláthatatlanná vált az SCCM 
kezelőfelülete, tehát éppen ideje volt a váltásnak. 


se 


tü System Center Configuration Manager (Connected to SCN — SCCM V.Next) 
File View Go 


lk Cal 74 WV 5 Administration b — Overview b v§ 
fereleltl adot esl ANN era a 
4 a Site Hierarchy Ú 1 Manage Configuration Manager v.Next infrastructure, to include sites, clients, security and permissions, alerts, and migration from Configuration Manager 2007. 
[d Boundaries 
já Senders 


4 (Ejj Overview ) d ! Overview 


4 Addresses 
) (7 Site Operations 
A. Cent Agent Settings 


) [E Security and Permissions 


z A 
Ar Getting Started a Actions 
Connect to a new site 
.. Site Hierarchy 
Manage site boundaries and site-to-site communication settings. 


a Alert Management 
EH Distribution Points ..1 Site Operations 
Manage site system servers, server roles, components, site maintenance, and status configurations. 


EZ) Distribution Point Groups 


) E Migration §. Client Agent Settings 
Configure default and custom dent settings. 
... Security and Permissions 
Manage administrative users, security roles, security scopes, certifications and run as accounts. 
4 Alert Management 


View and manage active alerts policies. You can specify whether to enable, disable, or delete the alert 
policies for the site. 


T : Distribution Points 
Manage distribution points. 

í7, Distribution Point Groups 
Manage distribution point groups. 





2 Migration 


tg Manage the migration of data from Configuration Manager 2007 sites to Configuration Manager v.Next 
ő Software Library sites. 





AR. Monitoring 





. Assets and Compliance 





ábra 32: Az SCCM konzol 


Természetesen a felület nem minden. Olyan újdonságok jelentek meg az adminisztráció terén, mint 
például a RBAC (Role Based Access Control), amelynek segítségével a különböző szerepkörrel rendelkező 
kollegák számára szabhatjuk testre a megjelenő funkciókat, és mindenki csak ahhoz fér hozzá amire a 
munkájához feltétlenül szüksége van. Jelenleg összesen 13 ilyen szerepkör található beépítve a 





termékben. 
(Icon) " Name Type 
ós Application Administrator role Built-In Role 
bp Application Deployment role Built-In Role 
d Application Editor role Built-In Role 
4 Asset Analyst role Built-In Role 
6 Asset Management role Built-In Role 
éz Compliance Settings Management role Built-In Role 
éz ConfigMgr Administration role Built-In Role 
4 Hierarchy Administrator Built-In Role 
6 Mobile Device Analyst role Built-In Role 
e Operating System Deployment Management role Built-In Role 
6 Read-only role Built-In Role 
d Remote Tools role Built-In Role 
4 Software Updates Management role Built-In Role 
ábra 33: Szerepkörök 
Integrált platform 


Az SCCM fő célja minden esetben a kliensek teljes életciklusának követése, támogatása. Az SCCM lefedi 
a teljes folyamatot melynek részei az OS és alkalmazások telepítése, frissítések terítése, 
konfigurációkezelés, majd a kliensek nyugdíjazása. Ezen felül a platform egy integrált megoldást kíván 
nyújtani, amely egyéb Microsoft alapú megoldásokkal közösen együttműködve tudja még hatékonyabbá 
tenni az infrastruktúra üzemeltetést és támogatást. A teljesség igénye nélkül ilyenek például a 
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BranchCache, DirectAccess, USMT, ACT. Természetesen nagyon fontos a többi System Center 
termékcsalád többi szereplőjével történő szoros együttműködés is, ezek közül talán leginkább 
kiemelendő a sokak számára valószínűleg még ismeretlen System Center Service Manager mellyel 
együttműködve megvalósítható az automatikus incidens- és változáskezelés. 


Kompatibilitás 

Úgy gondolom a cikk vége felé közeledve egyre inkább érezhető, hogy az új verzióban várható változások 
és az üzemeltetéshez szükséges szemléletmód váltás miatt az átállás nem lesz feltétlenül egyszerű 
folyamat , ezért mindenképpen érdemes néhány szót szólni a kompatibilitási kérdésekről. Gondolok itt 
arra, hogy vajon mi lesz a már meglévő SCCM2007 vagy akár SMS2003-as infrastruktúrák sorsa a 
jövőben. 


Természetesen a megjelenéskor már rendelkezésre fognak állni azon eszközök melyekkel megtehetjük a 
korábbi rendszereink direkt migrációját, ideértve az alkalmazásokat, klienseket, riportokat stb. 
Valószínűleg azon vállalatok lesznek kevesebben, akik egyik napról a másikra direkt migrációval cserélik 
le már meglévő SCCM infrastruktúrájukat, és úgy gondolom a fejlesztők sem voltak más véleményen. 
Lehetőség lesz ugyanis arra, hogy szép apró lépésekben térjünk át az új felhasználó központú 
szemléletmódra, miközben még a régi kliens centrikus módszereket is használjuk a rendszereink 
menedzselésére. Azt hogy ezt pontosan milyen formában fogják biztosítani sajnos még nem ismert, de a 
megjelenésig még majd egy év van hátra, így nyugodtak lehetünk, hogy van idő ezt is részletesen 
kidolgozni. 


Összefoglalás 

A cikk zárásaként csak annyit, hogy mindenképpen ajánlatos figyelni a következőkben megjelenő béta 
verziókat főleg a 2011 év elején megjelenő második béta lehet majd érdekes, mert minél előbb 
elkezdjük tanulni az új eszközöket és szemléletmódot annál egyszerűbb lesz az átállás megtervezése és 
kivitelezése. Természetesen a Technetklub és a magazin hasábjain is rengeteget fogunk még foglalkozni 
a V.Next képességeivel, amint újabb és pontosabb információk állnak rendelkezésünkre. 


Utószó 

Muszáj megjegyeznem itt is, hogy nagyon korai fázisban van a fejlesztés, egyelőre publikusan csak 
Béta1-es verzió érhető el, és csak 2011 első felében várható a Béta 2 megjelenése, ezért minden itt leírt 
információ a jelenlegi terveket és állapotot tükrözi, azok bármikor változhatnak. Abban azért biztos 
vagyok, hogy az alapvető koncepció nem fog lényegesen módosulni a megjelenés napjáig. 
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A Felhő felületén 


A Microsoft Online Services, közkeletű néven a BPOS Varga Gábor 

(Business Productivity Online Services) a Microsoft jól ismert 

vállalati alkalmazásainak új megjelenési formája: ahelyett, Microsoft 
Magyarország kft., 


hogy például a Microsoft Exchange-et telepítenünk kellene 
saját szervereinkre a felhasználás helyén, a Microsoft már 
adatközpontjában telepítette, és a felhasználóknak 
Megoldásértékesítési 


hozzáférést nyújt az Exchange funkcióihoz. A felhasználók . . 
tanácsadó 





megszokott, helyben telepített (on-premise) esetben, mégsem kell a rendszerek telepítésével járó 
manuális munkát elvégeznünk. Más szóval az informatikai erőforrást kihelyeztük a Felhőbe, de továbbra 
is helyben vesszük igénybe azt. 


Mindez azonban nem jelenti azt, hogy egy megközelíthetetlen, fekete dobozt használnánk, amelybe még 
az értő szemű adminisztrátor sem pillanthat bele. A Felhőben lévő fekete dobozon a Microsoft nemcsak 
a felhasználóknak, hanem az adminisztrátoroknak, sőt a fejlesztőknek is nyitott ablakot. 


Jó hír: Mivel a Microsoft a korábban már jól ismert termékeit helyezte át a Felhőbe, sok technikai felület 
megegyezik a megszokott Microsoft termék által nyújtott felülettel. Aki járatos például az Exchange Web 
Services (EWS) programozási felület használatában, ugyanezt az API-t meg fogja találni az Exchange 
Online szolgáltatáson is, néhány korlátozással. 
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Add Service Relerence ?7ÍXxI 


Ta see a list of available services on a specific server, enter a service URL and click. ao, Ta browse For 
available services, click. Discover , 


öddress: 





ittas: kurnapalliá 1 mail. micrasoftonline comtewstExchange, asmx stop 3 Discover je] 


SEFYVICES ; Caperakions : 






web Discovery Service 


The server needs ta authenticate vour reguest , 
szz Your credentials will be sent ta the server in clear text. 
Do von want ta continue? 









Please wait for s 


HENK 


famespace: 


 ferviceReference1 
HdZamced, , 3 (IK Cancel 3 


e 


ábra 34: Visual Studioban pontosan úgy hivatkozhatunk az Exchange Online EWS felületére, mint egy helyben telepített 
Exchange 2007 vagy Exchange 2010 EWS felületére 


Természetesen a felhő modellből következik néhány specialitás. A felhő modell előnyeinek egy 
legfontosabb forrása a megosztott használat, hiszen tudjuk, hogy minél nagyobb egy rendszer, annál 
kisebb az üzemeltetési költség egységenként. A megosztott használat ellenére az Exchange-ben 
megtaláljuk a Global Address List funkciót, de ez természetesen nem az Exchange Online rendszeren 
lévő több millió felhasználót tartalmazza, hanem csak azokat, akik az adott előfizető vállalathoz 
tartoznak. Emiatt érezheti úgy a felhasználó, hogy saját Exchange-en dolgozik — ezt nevezzük 
multitenant működésnek. Általánosságban elmondható, hogy azok a programozási technikák nem, vagy 
csak korlátozottan működnek, amelyek a szerverre feltöltendő programkódot feltételeznek, mert a 
Microsoft Online szolgáltatásnak biztosítania kell a felhasználók védelmét egymás futtatható kódjától. 
Nincs azonban akadálya annak, hogy a Microsoft Online-ra ráfejlesszünk a nyilvános felületeken 
keresztül. 


A Felhő néhány további ponton is más megközelítést követel, mint a hagyományos informatika. 
Példaként vegyük az Excel távolról futtatható változatát, az Excel Web Applicationt, amelyet a Microsoft 
az Office 365 szolgáltatás keretében is elérhetővé tesz 2011 tavaszán, igazi Felhő szolgáltatásként. Itt az 
helyi gépen beállított alapértelmezett mappát visszadó INFO() makrófüggvényt értelemszerűen nem 
használhatjuk, hibát ad vissza. Másik példa az időt visszadó MOST() — angol Excelben NOW() — 
függvény, amely nem a helyi PC, hanem a szerver idejét fogja visszaadni. Mindezen természetes 
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különbségek ellenére azt mondhatjuk, hogy az Excel Web Application a makrók futtatása tekintetében is 
közel ugyanazzal a tudással rendelkezik, mint a jól megszokott helyi Excelünk. 


Adminisztártorok számára fontos, hogy az Exchange Online Powershell parancsokkal menedzselhető, 
tehát itt sem kell egy új eszközt kezünkhöz idomítani. Ezeket a parancsokat a Microsoft Online Services 
Directory Synchronization eszközzel lehet telepíteni. A legfontosabb parancsokról itt olvashatunk: 


Bulk User Account Activation and Password Reset http://technet.microsoft.com/en- 
us/library/ee662252.aspx 


Migration Cmdlet Reference http://technet.microsoft.com/en-uszlibrary/cc742577.aspx 


Ha valamilyen feladatot korábban programkód írásával oldottunk meg, amelyet Exchange-hez 
fejlesztettünk, és az nem a régebbi API-k valamelyikét (pl. régebbi Exchange verziók DAV vagy szerver 
oldali CDO felületét) használja, akkor jó eséllyel könnyen tudjuk portolni a Felhőbe. A kliensre épülő 
megoldások természetesen szintén működnek, ilyenre példa lehet az Outlook Add-In, vagy az Outlook 
MAPI módszer használata. Működik továbbá az OWA Web Part technika is, ahogyan azt megszoktuk a 
helyi Exchange-nél, hiszen ezek is tulajdonképpen kliensre épülő programozási módok, még ha az OWA 
kiens a böngészőben fut is. 


A Sharepoint Online esetében egyelőre szűkebb az arzenál, de a Web Services felület jelentős része ott is 
meghívható, sőt a beágyazott Data Form Web Part akár külső adatforrásokat is képes megjeleníteni. 
Programozói szempontból az Office 365 hoz majd nagy előrelépést, amely bizonyos esetekben 
programkód feltöltését is lehetővé fogja tenni. 


Amennyiben a feladat megköveteli az Exchange Online-t vagy a Sharepoint Online-t kiegészítő 
programlogika írását, akkor erre a legjobb módszer, hogy azt nem az Exchange Online-on, illetve a 
Sharepoint Online-on belül helyezzük el, hanem egy Windows Azure alkalmazásban, hiszen onnan is 
hívhatjuk az Exchange Online-t, illetve Sharepoint Online-t. Erre egy konkrét példát tartalmaz az 
Exchange Online Developer Guide. 


A programozók számára több technikai dokumentumot is készített a Microsoft, amelyeknek a címe is 
igen beszédes: 


Az Exchange Online Developer Guide itt érhető el: 


htto://www.microsoft.com/downloads/en/details.aspx?disolayvlang-engFamilyID-Offa787d-79cd-43fd- 





b528-b47d45c7ea0d 


A Microsoft SharePoint Online Standard Developer Guide pedig itt: 
http://www.microsoft.com/downloads/en/details.aspx?FamilyID-d007f35e-375c-4b11-bc40- 





bc908g2bb224agdisplaylang-en 
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Exchange 2010 Service Pack 1 


Erősen tartja magát az a vélemény, miszerint az Exchange Petrényi 
kifejezetten az a termék, melyet csak az SP1 után szabad József 


komolyan venni. Szívem szerint küzdenék ellene, de a 
SRI Kft, senior 


technikai 
tanácsadó 


tapasztalat azt mutatja, hogy a legendának van egy halvány 
alapja, legalábbis az Exchange 2007 bevezetése megtépázta 


némileg ennek a patinás szoftverterméknek a jóhírét. 
Exchange Server 





A 2010-es verziónál azért ennyire nem rossz a helyzet. A ER MVP 
szoftver kibocsátási hibáit a Rollup Pack-ek folyamatosan javítgatták (4 jelent meg a szervizcsomag 
előtt), a funkcionalitási hiányosságok pedig messze nem voltak annyira ordítóak, mint a 2007-es RTM 
verzió esetén. Hogy akkor milyenek voltak? Pont erről fog szólni a cikk: milyen funkcionalitásbeli pluszt 


hozott nekünk az $SP1? 


A telepítéssel kapcsolatos újdonságok 

Mint közismert (hogy mondta, Safranek?), az Exchange alkalmazás telepítése előtt a számítógépet 
preparálni kell. Magyarul a Windows Server operációs rendszer változatától és a telepítendő Exchange 
szerepköröktől függően több-kevesebb képességet fel kellett ugrasztanunk a számítógépre. Nem volt ez 
olyan nagy ördöngősség, a Technet Library megfelelő fejezetéből kitúrtuk az adott helyzetben szükséges 
képességeket, ezeket beleírtuk az implementációs tervbe, aztán már jöhetett is a servermanagercmd 
vagy a Powershell, utána pedig reménykedhettünk a prereguisit check hosszú percei alatt, hogy jó 
fejezetet találtunk meg, és nem felejtettünk ki semmit. Nem meglepetés, hogy a folyamat ilyetén 
menetével a rendszergazdák nem volt igazán elégedettek, hiszen magánál az Exchange 
telepítőprogramjánál jobban senki nem tudhatta, milyen képességre is lesz még szüksége az 
alkalmazásnak - akkor miért is nem ő teszi fel ezeket a hiányzókat? 


Nos, az SP1-be ez a funkcionalitás már belekerült. Nem kell vacakolni a szükséges képességek 
telepítésével, elég csak bekattintani egy checkbox-ot és hajrá. (Felügyelet nélküli telepítésnél meg kell 
adni a /InstallWindowsComponents paramétert.) Rossz hír, hogy a telnet klienst ez sem teszi fel, 
márpedig anélkül egy Hub/Edge szerver olyan, mint Shrek szamár nélkül. 


(Amennyiben olyan képesség is szerepel a listán, amelyhez újraindítás szükséges, semmi gond, a restart 
után újra el kell indítani a telepítőt és az onnan fogja folytatni, ahol kihúzták alóla a delejt.) 


A Client Access Server szerepkör újdonságai 


ActiveSync 
Az Activesync funkció menedzselési lehetőségei szépen bővültek. 


Az Exchange Control Panel-ből a következő funkciók érhetőek el: 


e — Beállíthatjuk az alapértelmezett hozzáférési szinteket mindenféle mobileszköz számára. 
e — E-mail figyelmeztetést állíthatunk be arra az esetre, ha a mobil eszköz karanténba kerülne. 
e — Lekérhetjük a karanténba zárt mobileszközök listáját. 
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e — Eszközszintű szabályokat hozhatunk létre. 
e — Konkrét felhasználók konkrét mobil eszközeit engedélyezhetjük, illetve tilthatjuk. 
Ezeken kívül a felhasználók tulajdonságlapján is bővült az eszköztár: 


e — Kilistázhatjuk egy konkrét felhasználó mobil eszközeit. 

e — Távoli önmegsemmisítést kezdeményezhetünk konkrét mobil készülékekre. (Nem robban, csak 
törlődik a tartalma.) 

e — Törölhetjük a használaton kívüli mobil eszközök partneri kapcsolatait. 

e — Szabályokat hozhatunk létre, melyek egy konkrét mobil eszközt használó összes felhasználóra 
vonatkoznak. 

e — Végül innen is engedélyezhetjük, illetve tilthatjuk konkrét felhasználók konkrét mobil eszközeit. 


Eddig lehetőségünk volt engedélyezni a CAS szerveren az IRM integrációt. Jó is volt ez, abban az esetben, 
ha a mobil eszközökön is Windows operációs rendszer futott. A mobil világ többi része meg csak 
pislogott. Az SP1 lehetővé teszi - ActiveSync mailbox policy segítségével - hogy maga a CAS szerver 
hámozza ki az IRM-védett levél tartalmát és adja oda majdnem tisztán a mobil kliensnek. Ezzel már el 
tudnak bánni a nem Windows termékek is. (A majdnem tisztán azt jelenti, hogy azért egy jelzés kimegy 
arról, hogy ez eredetileg egy védett szöveg.) 


Outlook Web App 
Hah, a legfontosabb: skinek húzhatók a webes felületre. Jelenleg 27 elemű a készlet. 


Az Office Communication Server és az Outlook Web App együttműködésére szolgáló információk 
mostantól az Active Directoryban tárolódnak a web.config file helyett, ezáltal jóval könnyebben 
kezelhetőek. 


Annyira lehet, hogy nem közismert, de az owa virtuális könyvtáron a csatolásokra vonatkozóan nem csak 
block/allow kategóriák vonatkoznak, hanem létezik egy force save kategória is. Az ide tartozó 
csatolásokat meg lehet ugyan nyitni, de csak úgy, hogy megnyitás előtt a csatolás lementődik a kliens 
gépre. SP1 előtt ezek a fájlok kihagyták az XML/HTML forgalomra vonatkozó biztonsági ellenőrzést. Az 
SP1 után a ForceSaveAttachmenrtFilteringEnabled kapcsoló magasra állításával parancssorból (set- 
owamailboxpolicy, vagy set-owavirtualdirectory) beállítható hogy az ellenőrzés ezekre a kiterjesztésekre 
is vonatkozzon. 


Egy újabb ütős újdonság: az SP1 után már az OWA-ból is tudjuk módosítani a tartományi jelszavunkat. 
(Ehhez a registry-t kell megpiszkálni a CAS szerveren.) 


Vegyes 
Federation Trust esetén már használhatjuk az Exchange szerver saját maga által aláírt tanúsítványát is, 
nem szükséges lecserélni egy CA szerver által kibocsátottra. 


Megjelent a Reset Client Access Virtual Directory varázsló. A magam részéről láttam már olyat, hogy 
félrement egy telepítés és már rögtön az elején szanaszét állítódtak a CAS szerver virtuális könyvtárain a 
jogosultságok. És akkor még nem is beszéltünk azokról, akik bátortalan jogosultságmódosításokkal 
elindultak a Sötét Oldal felé, aztán váratlanul egy vulkán lávafolyamában találták magukat. Az 
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alapértelmezett könyvtárjogosultságokat végülis össze lehetett vadászni a netről és vissza is lehetett 
mindent állítgatni... de ez meglehetősen Hamupipőke jellegű munka volt. Ennek vége, itt van a 
Jótündér... akarom mondani, a varázsló. (Resetelés előtt azért elmenti egy logfájlba az aktuális 
jogosultságokat.) 


Történtek változások Client Throttling Policies téren is. Ezek olyan házirendek, melyek a 
klienshozzáférések okozta terhelést próbálják elviselhető értéken tartani. Az SP1 előtt csak azok a 
házirendek voltak alapértelmezésben bekapcsolva, melyek a hozzáférések számát korlátozták. Az SP1 
után már mindegyik működik helyből. Újítás az a viselkedés is, hogy mi történjen, ha egy válaszidő 
jellegű mennyiségre kihegyezett házirendben lépjük túl a beállított küszöbértéket? Az SP1 előtt ilyenkor 
négylábas megadás következett, azaz a CAS szerver bontotta a kapcsolatot. Az SP1 után valamivel már 
finomabb a reakció, a kapcsolat kivár, de nem bontódik fel. Emellett bejött két új cmdlet, melyekkel 
ezeket a terhelésszabályozó házirendeket tudjuk kezelgetni. (get/set-ThrottlingPolicyAssociation) 


A levéltovábbítás (Hub/Edge szerepkörök) újdonságai 

Nem tudom, mennyire ismert a MailTips funkció. Nagyon röviden arról van szó, hogy már a levél 
írásakor, de legkésőbb az elküldés előtt a szerver megvizsgálja, hogy számíthatunk-e levéltovábbítási 
hibára? (Túl nagy levél, nem létező címzett, meg ilyenek.) Az SP1 ezt a funkciót azzal bővítette, hogy 
immár az előzetes vizsgálat működhet federációs kapcsolaton, illetve Exchange Online-on keresztül is. 
Emellett némileg bőbeszédűbb lett a funkció, azaz jobban követhetjük az eventlogban, mit is csinál. 
Jöttek új alert, illetve performance counter változók is. 


A Message Tracking is főleg monitorozási funkciók terén javult, értsd eventlog, alert és perfcount 
bővülések. Illetve bejött egy felhasználói élményt növelő újítás is: ha a levél feladója delivery report-ot 
kért az elküldött leveléről, de az még nem állt össze, mert a Message Tracking még nem végzett, akkor a 
felhasználó az SP1 után egy udvarias és részletes magyarázó levelet kap arról, miért nem lehetett 
teljesíteni a kérését. 


Az SP1-es Transport szerverek mondhatni rajta tartják a kezüket a levelezés ütőerén. Az egyik trükkjük, 
hogy folyamatosan minősítgetik a feladott leveleket: lesznek alacsony és lesznek magas költségű levelek. 
Az utóbbin értünk olyanokat, amelyeknek túl sok a címzettje, túl nagy a belerakott csatolt fájl, és 
hasonlók. Ezeket a leveleket a Transport szerverek hátrébb sorolják és csak akkor küldik el, ha éppen 
ráérnek. Hasonló trükk az is, hogy a Transport szerverek figyelik a Mailbox szerverek RPC terheltségét, és 
amennyiben az túl nagy, akkor visszavesznek a lendületből. 


Bekerült a rendszerbe egy érdekes viselkedési mód, melyet Shadow Redundancy Promotion névvel 
illettek. Hogy ezt megértsük, kicsit mélyre kell fúrnunk. (Aztán legfeljebb a chilei bányászoknál 
visszafordulunk.) 


Maga a Shadow Redundancy a magas rendelkezésreállású rendszerek egyik építőeleme. Addig oké, hogy 
az adatbázisokból annyi másolatot üzemeltetünk, hogy minden elképzelhető katasztrófa esetén 
maradjon valahol egy belőlük... de mi történik azokkal a levelekkel, amelyek már bekerültek ugyan az 
Exchange organizációnkba, de még nem érkeztek meg az adatbázisba - és ekkor éppen lehal a Transport 
szerver? Ehhez a Microsoft némileg kibővítette az SMTP protokoll utasításkészletét, bevezetve ezzel a 
Shadow Redundancy fogalmát. Nagyon röviden arról van szó, hogy a Transport szerver továbbítja a 
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levelet, de emellett berakja egy Shadow Oueue-ba is, ahol addig őrzi, amíg meg nem győződik arról, 
hogy a következő Transport szerver át nem vette. (Ehhez a plusz kommunikációhoz kellenek a plusz 
parancsok.) 


A gondok akkor kezdődnek, amikor az Exchange 2010 Transport szerver olyan SMTP szervertől vesz át 
levelet, mely nem ismeri a Shadow Redundancy technikát. (Azaz gyakorlatilag a külvilágból, illetve a 
korábbi Exchange szerverektől.) A Transport szerver, illetve ekkor inkább Edge szerver, ilyenkor nem 
igazolja vissza egyből a levél megkapását, hanem vár arra, hogy a levél ténylegesen is eljusson a címzett 
Mailbox szerveréig. De mi van akkor, ha mondjuk egy hálózati hiba miatt a belső levelezési lánc 
ideiglenesen megszakad? A külső levelező szerver egyre türelmetlenebbül vár, a levél végülis 
megérkezett hozzánk... valamit csinálni kell. Az Exchange 2010 RTM ilyenkor a timeout előtt pár 
pillanattal nagy bátran visszaküldött egy igazolást, hogy minden rendben, aztán reménykedett, hogy 
tényleg rendben is lesz. Az S$P1 viszont bevezette a Shadow Redundancy Promotion viselkedést: az Edge 
szerver keres odabent akárhol egy működő Transport szervert és elküldi neki a levelet. Ez már SR 
kompatibilis módban megy, tehát a levél átkerül a következő szerverre, belekerül az Edge szerver 
Shadow Oueue-jába... azaz egészen biztosan elszállításra kerül valamikor, valahogyan. Nyugodtan lehet 
értesíteni a feladót, hogy a levelét megkaptuk, és az garantáltan el fog jutni a felhasználó postafiókjába. 


Tudjuk, hogy a Transport szerverek beépítetten tudják a terheléselosztást, amennyiben több is található 
belőlük egy organizáción belül. Az S$P1 ezen az algoritmuson is módosított egy kicsit: korábban ugyanis, 
ha kiesett egy Transport szerver, a terhelés nem egyenletesen oszlott meg a maradék szervereken. 
Innentől viszont igen. 


Le lettek cserélve a receive konnektorok. Az új verzió már támogatja SMTP esetén az Extended 
Protection for Authentication-t, mely gyakorlatilag TLS csatornába bújtatott Integrated Windows 
autentikációt jelent. 


A nagy változtatásokból a send konnektorok sem maradtak ki. Az SP1-ben definiálhatunk úgynevezett 
betonbiztos levelezési útvonalakat, melyek akkor is működnek, amikor nem. Hülyén hangzik, pedig nem 
az. Tipikusan ilyen útvonal a felhőbe, azaz az Exchange Online felé mutató konnektor. Elképzelhető, hogy 
pillanatnyilag nem érhető el - mert pont akkor vált elérhetetlenné egy kapcsolat - de a következő 
másodpercben már a helyére is állt egy másik. Felesleges lenne, ha ilyenkor a levelek NDR-rel 
pattannának vissza. (Az Exchange Online kapcsolat egyébként is furán működik egy kicsit, normál 
üzemmódban is kaphatunk olyan hibaüzeneteket, melyek más kapcsolatnál bontást eredményeznek. Itt 
nem.) 


Érdemes megemlíteni, hogy az SP1 nem csak hozott, hanem vitt is. Amennyiben Edge szervert 
használunk, melyen beüzemeltük a gyári spamszűrést, akkor az SP1 telepítése után kellemetlen 
meglepetésben lesz részünk: az SCL meghatározásához szükséges spamminta adatbázis a továbbiakban 
nem fog frissülni. A Microsoft hivatalos álláspontja szerint a spamminta adatbázis frissítését 
összekötötték a vírusminta adatbázis frissítésével, erre a kunsztra viszont csak a Forefront Protection for 
Exchange Server 2010 lesz képes. 


Jogosultságbeli változások 
Az RBAC-ba (Role-based Access Control) bekerült egy új hatókör, a database szkóp. 
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Egy újabb szemléletbeli váltás történt a jogosultsági rendszerben. SP1i előtt az Exchange 
adminisztrátorok képesek voltak felhasználókat létrehozni, törölni a címtárban, illetve hozzáfértek nem 
egészen Exchange jellegű tulajdonságokhoz is. Ennek most vége. 


Mostantól az RBAC-hoz tartozó elemek (management role groups, managment role assignment policies) 
elérhetők Exchange Control Panel-en keresztül is, grafikusan. (Hiphiphurrá.) 


Adattárolást érintő változások 
Az Exchange 2010 RTM lekorlátozta a felhasználónkénti hozzáférések számát az adatbázisokhoz. Az $P1 
ezen belül megnövelte az adminisztrátori hozzáférések limitjét 64000 session/server értékre. 


Az egyik kedvencem. A 2010 SP1 előtti bármelyik Exchange verzió esetében ha megsérült egy, vagy több 
postafiók, akkor le kellett csatolni az adatbázist, majd offline állapotban ráküldeni az lsinteg parancsot. 
Az SP1-ben bejött egy új cmdlet (new-mailboxrepairreguest), mely képes megvizsgálni egy-egy 
postafiókot és kijavítani az esetleges sérüléseket. Mindezt online módban. 


Ez se rossz. Kapunk egy szkriptet (troubleshoot-databasespace.ps1), mely negyedóránként lefut és 
figyeli, mennyi az üres hely az adatbázisok és logok alatti merevlemezeken. Ha ez az érték 259 alá esik, 
akkor megvizsgálja, hogy nem a logfájlok hirtelen megugrott szaporodása vitte-e el a helyet? Ha igen, 
akkor a szkript megvizsgálja az adatbázis 25 legjobban pörgő postafiókját és a legnagyobb forgalmúakat 
karanténba vágja. (Hat órán keresztül a postafiókok elérhetetlenné válnak.) Amennyiben ezzel sem tudja 
lecsökkenteni a növekedést, akkor egyrészt riaszt, másrészt kiveszi az illető adatbázist az ún. 
Provisioning adatbázisok közül. (Az Exchange 2010 esetében nem kell konkrétan megmondanunk, melyik 
adatbázisba szeretnénk, hogy kerüljön egy új postafiók. Elég csak megadnunk egy listát - provisioning list 
- és az ebben szereplő adatbázisokból választ a szerver egyet, load balance alapján.) Amennyiben a 
szkript tíznél több postafiók esetében talál túl intenzív használatot, rendszerhibát jelez. 


Kapunk egy hasonló szkriptet arra az esetre, ha egy adatbázis válaszideje durván megnőne. 
(troubleshoot-databaselatency.ps1) 


Radír. Az SP1 hozott egy új cmdletet: remove-storemailbox. Ez gyakorlatilag kipurgálja a megnevezett 
postafiókokat. Aktív postafiókra nem működik, csak valamilyen módon törölt postafiókokra. 
Konkrétabban: 


e — Soft-deleted postafiókok: Amikor egy postafiókot átmozgatunk egy másik adatbázisba, nem 
törlődik egyből a régiből, hanem ún. soft-deleted állapotba kerül. (Arra az esetre, ha vissza 
akarnánk csinálni az átmozgatást.) 

e . Removed, vagy disabled pstafiókok: Amikor egy postafiókot vagy kitöröltünk, vagy lecsatoltunk 
egy felhasználóról. 

Alaphelyzetben mindkét kategória esetén a törlés csak a retention time lejárta után történik meg. A 
remove-storemailbox parancs ezt gyorsítja fel. 


A public folderek is kaptak néhány új szkriptet. Ezek elsősorban a replikációkra vonatkozó statisztikákra, 
illetve hibajavításokra vonatkoznak. Ezenkívül bekerült a grafikus konzolba a kliens szintű jogosultságok 
állítgatása a foldereken. 


HT 


Végül egy figyelmeztetés. Az SP1-ben megváltozott az adatbázis séma, azaz RTM szerverről lecsatolt 
adatbázist - "database portability" ide, vagy oda - nem tudunk felcsatolni SP1-es szerveren. Na meg 
fordítva sem. 


Postafiókokat érintő változások 

Elismerem, nem ez a legnagyobb horderejű változás, de azért említsük meg: létre tudunk hozni 
csoportnév-konvenció házirendet, azaz innentől csak a névkonvenciónknak megfelelő nevű levelezési 
csoportokat leszünk képesek kreálni. 


Megjelent egy csomó új cmdlet, melyek segítségével aszinkron módon tudunk közvetlenül pst-be 
exportálni, illetve pst-ből importálni. 


A lágytörlésről (khmm) már esett szó, említsük meg egy másik aspektusból is. Ha egy postafiók 
mozgatása behal, akkor az SP1 után nem kell aggódni, az eredeti helyéről nem törlődött a tartalom, 
visszaállítható. 


Az egyik legnagyobb durranás: az SP1-ben már elválasztható egymástól a felhasználó éles postafiókja és 
a személyes archív postafiókja. Eddig ezt a hiányosságot okoltam leginkább azért, hogy annyira még nem 
terjedt el a Personal Archive. Innentől a személyes archívum külön adatbázisban és külön szerveren is 
tárolható, a kezelése teljesen különválik a felhasználó tényleges postafiókjától. (Ha nem lelkendeznél 
még kellően, gondolj bele az ESE adattárolási mechanizmusába.) 


A következő újdonság bejelentésekor játszódik némi mosoly a szám szélén. Azon ember mosolya, aki 
már egész varjúsereget is látott már karókra tűzve. Arról van szó, hogy az SP1-es verzióban már létre 
tudunk hozni hierarchikus címlistákat is. Ha visszaemlékszünk, ezzel a képességgel a 12 évvel ezelőtt 
regnáló Exchange 5.5 is rendelkezett. Igaz, akkor még saját Directory Service szolgáltatása volt. Aztán 
kihúzták alóla és elnevezték Active Directory-nak. A címlisták pedig eleinte (v200O/2003) ldap 
lekérdezések, később pedig (v2007/2010) opath filterek alapján álltak össze, kemény, egy dimenziós lista 
formájába. Ez változott meg, mostantól simán le tudjuk képezni a címlistákba a cégünk belső 
hierarchiáját, ami mindenképpen egy kellemesebb felhasználói élmény. 


A magas rendelkezésreállást érintő változások 

Continuous Replication - blokk módban. Emésszük egy kicsit. Eddig ugye úgy ment a logreplikáció, hogy 
amint "elkészült" egy logfájl, fájlszinten át lett másolva a másik/többi node-ra. Habár a logfájlok mérete 
pont az adatvesztés minimalizálása miatt 2007-ben 5 MB-ról 1 MB-ra csökkent, de azért egy elveszett 1 
MB-os logfájl is rendes galibákat tudott okozni. A blokk mód megértéséhez megint fúrjunk egy kicsit. 
Általánosságban bármilyen változás történik, maga a változás nem közvetlenül a logfájlba íródik, hanem 
egy ún. logbufferbe. Amikor ez megtelik, akkor megy ki az infó magába az 1 MB-os logfájlba. Blokk mód 
esetén már az elemi változás íródik bele párhuzamosan minden node logbufferébe. Azaz ekkor már nem 
kell várni arra, hogy maguk a logfájlok replikálódjanak. 


Enhanced Datacenter Activation Coordination (DAC) támogatás. Itt már átlépünk a Site Resiliency, azaz 
telephely szintű forró redundancia világába. Maga a DAC egy Site Resilience üzemmód, melyben 
cmdletek segítségével valósítjuk meg az átállást. A 2010 RTM verzióban a DAC mode csak akkor volt 
használható, ha legalább 3 node-ból álló DAG rendszerünk volt. Az S$P1 ebben is lazított, immár 2 node- 
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os DAG esetében is működik a DAC mode. (Mielőtt legyintenénk, gondoljunk bele, mi is van akkor, ha az 
a telephely dől le, ahol az egyik node mellett a witness is van?) 


Ezen a területen is kaptunk egy szakajtó segédszkriptet: 


e . CheckDatabaseRedundancy.ps1: Mint a neve is mutatja, leellenőrzi, hogy adatbázis-redundancia 
téren minden rendben van-e? 

e — Start/StopDagServerMaintenance.ps1: Az első parancs előkészíti a DAG node-ot karbantartásra. 
(Elmozgat róla minden aktív adatbázist és DAG funkcionalitást. illetve blokkolja, hogy a szerver 
részt vegyen a DAG működésében.) A második meg visszacsinálja mindezt. 

e — CollectOverMetrics.ps1: Ez a szkript már létezett korábban is, de most ki lett bővítve. Ha 
lefuttatjuk, összegyűjti az összes rendelkezésére álló adatot a switchover, illetve failover 
esetekről. (A bővítés gyakorlatilag azt jelenti, hogy már ismeri a blokk módot.) 

e — CollectreplicationMetrics.ps1: Szintén már létező szkript kibővítése. Az a trükkje, hogy real time 
képes monitorozni az éppen zajló logreplikációt. 


Emellett néhány funkcionalitás feljutott az EMS-ből az EMC-be, illetve jelentősen felgyorsult a 
switchover/failover folyamat is. 


Házirend és megfelelőség az SP1-ben 
Erről a területről csak szemezgetnék, mert a rengeteg apró változást inkább nem sorolnám fel. 


Retention Policy 
Az SP1-ben már a Calendar, illetve a Tasks default folderekre is tudunk retention policy jelölést rakni. 


A felhasználók az Exchange Control Panelből be tudják jelölni azokat a leveleket, melyekre nem 
szeretnék, hogy ráessen a retention policy. 


Discovery 

Mielőtt az adminisztrátorok ráküldenék a tényleges tömeges keresést a postafiókokra, visszajelzést 
kapnak, hogy mekkora eredményhalmazt kapnának. Ez anélkül segítheti őket a keresőkifejezés 
finomításában, hogy meg kellene várniuk a tényleges keresés eredményét. 


Az adminisztrátorok megjegyzésekkel láthatják el a talált leveleket. 
A keresés kiszűri az eredményhalmazból a duplikátumokat. 


Information Rights Management (IRM) 

OWA-ból anélkül is megtekinthetjük az IRM védett csatolt fájlokat (WebReady document viewing), hogy 
azokat a hozzájuk tartozó alkalmazásokkal megnyitnánk. (Természetesen ez nem minden fájltipusra igaz, 
csak bizonyos támogatottakra.) 


Az IRM már cross-organization környezetben is támogatva lett. 


Exchange szerepkörönként logolhatjuk az IRM-mel kapcsolatos eseményeket. 
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Az Unified Messaging szerepkör változásai 
Tekintve, hogy ez a szerepkör a legritkábban előforduló szerepkör a vadonban, inkább csak röviden 
felsorolok néhány változást, a teljesség igénye nélkül. 


e — Az ECP-ben is megjelenik a felhasználó hívási statisztikája, illetve a hívási logja. 

e — ECP-ből is lehet menedzselni az UM funkciókat. 

e . Immár tudunk organizációk között is mozgatni UM-enabled postafiókot. 

e — Caller Name Display támogatás. 

e — Test-ExchangeUMCallFlow cmdlet: tesztelhetjük az UM kapcsolatot és magának a hívásnak a 
menetét. 

e . Támogatja a Lync Server 2010-et. (Az OCS 2007 utódját.) 

e — 11 új nyelvi csomag, ebből négy támogatja a felolvasást (Voice Mail Preview) is. Az utóbbiak: 
kanadai angol (Im a lumberjack, and Im okay), lengyel, portugál és spanyol. A magyar a 
fasorban sincs. 


Auditálás 

Az auditálás mindig is egy kényes feladat. Ha túl kevés információt gyűjtök, akkor pont az nem lesz 
benne, amire kiváncsi vagyok. Ha túl sokat, akkor benne lesz ugyan, de nem találom meg. Az SP1 úgy 
próbálja feloldani az ellentmondást, hogy rágyúr a keresésre. Ez konkrétan azt jelenti, hogy az EMS-ből 
indíthatunk tetszőleges részletességű keresést, a parancs kimenetele lehet egyszerűen a képernyő, egy 
xml! fájl, vagy email egy tetszőleges címre. 


Jó, de mi is az, amiben kereshetünk, azaz mit is auditálunk? Az adminkodást. Azaz minden művelet, mely 
az Exchange rendszer konfigurációját érinti, rögzítésre kerül. (Konkrétan maga a keresés is, hiszen az is 
parancs kiadása.) 


Az SP1 emellett bevezeti a postafiók auditálást. Minden megmozdulás auditálható, mely érinti a 
postafiókot, függetlenül attól, hogy egy adminisztrátor, egy delegált személy, vagy maga a tulajdonos 
követte el. Mit értünk megmozdulás alatt? Gyakorlatilag mindent: kapcsolódás postafiókhoz, levelek 
mozgatása, törlése vagy egyszerűen csak a megnyitása. Durva, nem? Ha belegondolunk, mennyi adat 
kerül rögzítésre, rögtön örülni fogunk a keresés feljavításának. 


A log eredménye nem az eventlogba kerül, hanem magába a vizsgált postafiókba. Engedélyezése a set- 
mailbox paranccsal történik - azaz postafiókonként szabályozható. 


Zárszó 

Nagyjából ennyi. Habár nem minden változást soroltam fel, de a lényegeseket igen. Első ránézésre 
ijesztően hosszúnak tűnhet a lista, de vizsgáljuk meg alaposan a változásokat: egyik sem olyan, melynek 
hiánya nagyon megnehezítené a rendszer használatát. Okos dolgok, jobb lett tőlük a termék... de ezek 
nélkül sem rossz. Azaz Exchange téren a kizökkent világ kezd valóban helyreállni: a szervízcsomag plusz 
igényeket elégít ki, nem pedig alapfunkciókat. 
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